ANSI C -- preprocessing

Doug Gwyn gwyn at brl-smoke.ARPA
Tue Dec 16 03:50:51 AEST 1986


In article <109 at decvax.UUCP> minow at decvax.UUCP (Martin Minow) writes:

More good ideas that have already been discussed by X3J11 and
decided differently (but don't let that stop you from making
good arguments for adoption of your suggestions!).  Perhaps
by summarizing my understanding of the current committee
position (UNofficially) I can help you frame counter-arguments:

>Page 75, line 27.  An identifier not currently defined as a macro should
>produce a diagnostic message.  Whether or not the diagnostic is fatal
>should be implementation defined.

(Basically, as I understand it the way to guarantee a diagnostic
for a violation is to make the condition a Constraint.)

The requirement that an undefined identifier evaluate as 0 is for
compatibility with existing practice (Reiser CPP on UNIX).  It is
hard to imagine that there is much existing code that would depend
on a diagnostic being produced, but there is definitely a lot of
existing code that depends on the behavior defined in the draft.

>Page 75, line 32ff.  The result of preprocessing character constants should
>be the same as the result of executing the equivalent statements.  A single
>character constant shall have a negative value if it would have a negative
>value according to the semantics for character constants given on page 25,
>line 35.

I believe the lack of such a guarantee is intended to help
cross-compilation environments.  Basically, preprocessing
arithmetic is done (using long integers) at compile time,
and emulating the run-time arithmetic would impose a new
burden on implementations.

>Page 82, line 10ff.  An unrecognized #pragma should result in a diagnostic
>message.

Sorry, I can't go along with this.  The idea of #pragma is
advisory, so such directives can generally be ignored.



More information about the Comp.lang.c mailing list