🚀 go-pugleaf

In article <8741@megaron.arizona.edu> mike@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!"