🚀 go-pugleaf

daniel@terra.ucsc.edu (Daniel Edelson) writes:

>There is no constraint to the effect:

>	``The #error directive shall not be present.''

>Therefore, a strictly conforming program may contain #error.

>The question is: must a conforming implementation "successfully 
>translate" any strictly conforming program?
>*) If yes, a program containing #error must produce an
>   executable program. Implementations that don't are broken.
>*) If no, a conforming implementation may fail to translate any 
>   program whatsoever.

>What is the correct interpretation?

Not necesarily either of the above.

An #error directive in a section of source code which is being ignored
(#if'd out, for example) is, um, ignored.

If the #error directive is processed, the standard requires that a
diagnostic be issued.  The standard cannot discuss issues such as
"producing an executable program", since there may be no such notion
in a given implementation.  (What would it mean in an interpreter
which never generates any machine code at all?  Do you require that
an interpreter generate a separately loadable and executable image
to be considered conforming?)

The Rationale states, "It is the intent of the Committee, however,
that translation cease immediately upon encountering this directive..."
The problem is that there is no way to put this language into the
standard itself.  The Rationale goes on to say that the alternative
would be to put enough trash in the program to cause the translator
to choke.  This seems inelegant.

Going to the explicit question:
>The question is: must a conforming implementation "successfully 
>translate" any strictly conforming program?

The answer is no, because of translation limits which may be present.
A strictly conforming program (without #error directives) may be
rejected by a conforming implementation if it hits all of the
translation limits.  (The implementation must handle at least one
such program, but need not handle all such programs.  This peculiarity
arises from the impossibility of testing a requirement on "all programs".)
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com