__STDC__ and non-conforming ANSI C compilers

Farrell Woods ftw at masscomp.UUCP
Wed Jan 18 01:10:57 AEST 1989


In article <8731 at megaron.arizona.edu> mike at arizona.edu (Mike Coffin) writes:
>1) If the intent was that only conforming compilers define __STDC__,
>   why is this loophole in the standard?  I.e., why does the standard
>   specify "1" as THE value for __STDC__?  Is it too late to change
>   things, if the wording does not correspond to the intent?

I think this was explained before.  It is a mechanisim to allow future
revisions to the standard.  #if (__STDC__ == 1) will mean that this
compiler (fully) conforms to what is currently the pANS.  If a future
standard should emerge, then the (fully) conforming compilers for
that standard will set __STDC__ to 2, etc.  Mr. Gwyn will correct me
if I'm wrong ;-)

>2) Why is #ifdef "as likely to be used" as #if?  The latter is shorter
>   and tests for exactly what the standard specifies; the former is
>   longer and doesn't.  It seems to me that using #ifdef for this
>   purpose is just a bug, pure and simple.

Other have indicated that some compilers produce warnings if a
undefined constant appears in a #if expression.  This is weak, though.
#ifdef __STDC__ is supposed to answer the yes/no question of whether
this is a fully conforming compiler.  #if __STDC__ will of course work,
but it answers a slightly different question.

>3) I suppose there is a need to determine whether the compiler is
>   exactly "conforming", although I'm not sure what you would do if it
>   wasn't.  But the need is far more pressing for a flag that answers
>   the question "is this a K&R compiler or an ANSI compiler?"  How do
>   we tell the difference between a K&R compiler and an ANSI compiler
>   that is invoked in such a way that it's nonconforming?  (E.g., 
>   "cc -DFOO".)  Does the standard say anything about this?  Shouldn't 
>   we adopt some convention before we have chaos?

I don't know if I quite understand the question.  I don't believe that there
is a "strict" interpretation of K&R; I suspect that is why we have X3J11
to help sort this out.  If I invoke a conforming compiler with "cc -DFOO",
but my program has #ifdef __STDC__ in it, how does this break conformance?

>4) In view of the fact that "#ifdef __STDC__" doesn't tell us
>   anything, according to the standard (as I understand it), what is
>   wrong with using it to indicate "rough ANSI compliance"?

That's the whole point: if vendors abuse __STDC__, then its meaning becomes
eroded.  __STDC__ only tell us something useful if vendors of non-conforing
compilers respect its stated meaning.  Obviously, X3J11 doesn't own
the name "C" as a trademark, as the DoD does "Ada".  Those of us who use C,
and those who took their time to hammer out the pANS can only hope that
vendors do not abuse __STDC__.  When they do, we can raise a stink and
threaten not to buy their compilers, etc., but we can't sue them.

Here's another thing to think about.  If each vendor that "almost" has all
features of the pANS and decides to #define __STDC__ 0, how can my program
figure out which subset of the pANS is in effect if I take the program
from compiler A to compiler B?  It really is a all-or-nothing shot.

-- 
Farrell T. Woods				Voice: (508) 692-6200 x2471
MASSCOMP Operating Systems Group		Internet: ftw at masscomp.com
1 Technology Way				uucp: {backbones}!masscomp!ftw
Westford, MA 01886				OS/2: Half an operating system



More information about the Comp.std.c mailing list