__STDC__ and non-conforming ANSI C compilers

[Doug Gwyn]

In article <274 at microsoft.UUCP> w-colinp at microsoft.uucp (Colin Plumb) writes:
>gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) wrote:
>> There is no way you can know what use a programmer is making of __STDC__.
>But if, as is very popular, they use ##ifdef __STDC__ as a
>switch to tell whether to use ANSI cpp-isms or Reiser tricks for
>token-pasting, or whether they can include prototypes, or use void *, etc.,
>it'll work.

What I'm telling you is, NO, it will NOT work, because there is no
standard for the meaning of __STDC__ except in the context of full
ANSI conformance.  If an implementation can properly support WHATEVER
I might choose to key on __STDC__, then it is in effect standard
conforming and therefore should set __STDC__ to 1.  Problems arise
when a non-conforming implementation thinks it is "close enough" and
consequently defines __STDC__ (whether to 0 or 1 is immaterial, since
#ifdef __STDC__ is as likely to be used as the more paranoid
#if __STDC__).

X3J11 was quite serious in setting forth strict injunctions against
name space pollution, etc.  __STDC__ was specified so that program
source code could have a way to determine whether it was being
compiled in a known environment or in some uncontrolled one.  This
is a very crisp distinction.  To rip off the indicator to denote
some ill-defined environment simply exhibits the vendor's lack of
understanding how important to the application developer strict
control over the implementation environment is.  __STDC__ should be
considered to lie entirely within "C standard" turf, off-limits to
non-standard implementations.  If you need "feature flags", invent
some, as is commonly done (usually, Makefiles can be configured to
enable the appropriate set of feature flags for each specific
target environment).  You need more than a single "feature flag"
anyway!

One thing for sure -- I'm not buying compilers that screw this up.