__STDC__ and non-conforming ANSI C compilers
Mike Coffin
mike at arizona.edu
Tue Jan 17 06:45:40 AEST 1989
>From article <9391 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn ):
> 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__).
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?
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.
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?
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"?
--
Mike Coffin mike at arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2}!arizona!mike
Tucson, AZ 85721 (602)621-2858
More information about the Comp.std.c
mailing list