[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax>
- Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
- From: Dan L. Pierson <pierson%mist@multimax.ARPA>
- Date: Wed, 07 Sep 88 15:23:26 EDT
- Cc: cl-compiler%sail.stanford.edu@Multimax
- In-reply-to: Your message of Wed, 07 Sep 88 20:01:41 -0000. <firstname.lastname@example.org>
Um, unspecified is unspecified: the implementation can do whatever it
wants. Soemthing in the C stabdard (pragmas, I think) was defined in
this way, and for a while gcc would run rogue, or gnu emacs, or, ...
-- depending on what it could find -- whenever it encountered a
So this particular problem is not a reason to prefer "unspecified" to
"is an error" -- both allow "crash and burn".
Obviously, we need a term which allows a reasonable number of
implementation options without allowing GCC-like obnoxious behavior.
This is part of what the whole committee has to consider when we
decide what our new set of error terms should be. My claim is simply
that we badly need to break "is an error" down into some more
controlled and useful cases everywhere in the standard.
PS: In fact the CLOS spec defines "unspecified" as harmless at worst.
There is another term, "undefined", that allows crash and burn.
(88-002R, pp. 1-6,1-7)