__STDC__ defined as zero a problem

[Doug Gwyn]

In article <225800190 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>On the other hand, though __STDC__ is supposed to be defined as 1 
>for comforming compilers , and not redefinable, (is this correct,
>standards gurus?) it might be possible in a not-really ANSI-C
>compiler to make __STDC__ be defined as 0, and redefinable. The
>standard surely shouldn't object to this, should it?

This topic has previously been discussed to death.  Here is a summary:

There are already non standard-conforming implementations that predefine
__STDC__ to almost anything you could imagine, including 0, 1, and 2.

The Standard requires that a conforming implementation predefine it to
be precisely 1 (for this version of the Standard).  Small integral
values greater than 1 are intended to be defined by future revisions
of the Standard.  Application redefinition or #undef of __STDC__ is
prohibited.  The purpose of __STDC__ is to allow application source
code testing for compilation in a Standard C environment, so that the
code can exploit post-K&R standard features in such an environment.
In a non-standard environment, there are no guarantees about the
environment, although as a practical matter many applications (for
example, UNIX=based ones) will be able to make reasonable assumptions
about the available environment.

The Standard does not, because it cannot, constrain non-conforming
implementations.  However, when __STDC__ was invented by X3J11 it was
clearly intended to be the "property" of Standard C, with the hope
that C compiler vendors would cooperate with its intended purpose.
Some vendors, including AT&T and Microsoft, appear to believe that
setting __STDC__ to 0 when their nominally standard-conforming
compiler is operated with Standard-violating options enabled is a
legitimate thing to do.  I think it is clear that vendors who set
__STDC__ to 1 in such circumstances are in the wrong, and those who
set __STDC__ to 2 or some other such small positive value are just as
wrong (since they cannot possibly predict what extensions will be
supported by a future revision of the Standard).

My recommendation is for standard-conforming implementations to preset
__STDC__ to 1 (as the Standard requires) and for ALL others to leave
__STDC__ undefined.  Less acceptable but still better than other
alternatives is for non-conforming but "mostly ANSI" implementations
to preset __STDC__ to 0, even though there is no standard meaning for
such a value, which implies that portable applications cannot rely on
it.  In no case should applications be allowed to change the value of
a preset __STDC__.

Portable applications are entitled to assume that everything specified
in the Standard is available if they find __STDC__ predefined.  Really
they should not have to resort to further tests, but given the fact
that vendors have been taking liberties with __STDC__, it would be
wise to also test for __STDC__ > 0 before assuming that EXACTLY those
things specified in the Standard are available.

If your compiler vendor predefines __STDC__ in a non standard-conforming
implementation, I urge you to complain loudly to the vendor.