__STDC__ and non-conforming ANSI C compilers

[John Myers]

In article <9415 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>I consider the "cc -DDEBUG" issue negotiable, since it takes an
>explicit user action to violate the standard constraint, so perhaps
>it is appropriate to place the burden of responsibility on the user
>in such a case.  For example, the compiler documentation might say:
>"Although __STDC__ is always 1, if you predefine macros then you do
>not have a Standard-conforming implementation, so beware!"

By the same argument, "cc -standard-extensions" (which can be thought
of as prepending "#define asm __builtin_asm", "#define unix" and other
such stuff to the source file) could legitimately have __STDC__
predefined.  The fact that most implementations will use something
like the absence of the switch "-strict-ansi" to do this is somewhat
irrelevent.

Namespace pollution can hardly be considered grounds for undefining
__STDC__.  As has been mentioned before, __STDC__ is useless for
dealing with pollution.  There's no strategy one can use on the other
side of the #else--either one is going to get burned or one is not.
With such things as token-pasting, <stdarg.h>, and function
prototypes, one can use traditional methods (Reiser hacks,
<varargs.h>, and old-style declarations) on the other side of the
#else and have an extremely good chance of its working.

I agree that defining __STDC__ to be 0 is a crock.

(On the issue of libraries, a compiler could do the same thing as 
"gcc -ansi -pedantic" and claim to be a "conforming freestanding
implementation."  Who says there are no subsets of conformance?)

-- 
_.John G. Myers		Internet: John.Myers at cs.cmu.edu
(412) 268-5655		LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
"The datefield parameter is a six byte, null-terminated string encoding the
 UNIX date in base 64." -- Andrew Message System documentation.
--