__STDC__ and non-conforming ANSI C compilers
Doug Gwyn
gwyn at smoke.BRL.MIL
Wed Jan 18 08:40:43 AEST 1989
In article <8741 at megaron.arizona.edu> mike at arizona.edu (Mike Coffin) writes:
>I still say, the most important distinction is between C environments
>that "essentially" follow K&R and those that "essentially" follow pANS.
Now, that's an argument I don't buy. The pANS is essentially a superset
of "K&R C" as we're loosely using the term here. So testing __STDC__
does not make the proper distinction. In fact there is no easy way to
test with #ifs etc. what kind of non-Standard conforming implementation
you're dealing with. That's simply a historical fact of life, with
which most of us who port C code have had to figure out ways to cope.
__STDC__ was never intended to help with that, because it can't.
>These are practical problems, for which I see no solution at the
>moment.
Yes, and since __STDC__ is not defined at all in most existing C
environments using it is no solution either, except that the answers
to your "is this ANSI C feature available" questions are all supposed
to be "yes" for __STDC__ and "who knows?" for non-__STDC__.
>Strict compliance isn't something that buys me much. I don't have
>much use for a flag that will get turned off if the compiler is
>invoked with "cc -DDEBUG". Where will I use it?
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!"
More information about the Comp.std.c
mailing list