[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


>     "Crash and burn" does seem a bit excessive.  The problem is that the
>     error terminology in CLtL is too vague.  We could borrow the conventions
>     the CLOS folks came up with and say that the behavior is "unspecified"
>     instead.
> I think that we have to do that in general.  One of the things that
> the whole committee really needs to decide in October is to use one of
> the two new error terminologies (CLOS or Pitman) everywhere.

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".