__STDC__ and non-strictly conforming ANSI C compilers

[Henry Spencer]

In article <9199 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The implementation should not predefine __STDC__ when the compiler
>or library are invoked in non-conforming ways.  I realize that that
>means that
>	ansi_cc -PREDEF near __near foo.c
>would have to, because of the standard-violating predefinition of
>a symbol not reserved for implementation use, turn off its
>predefinition of __STDC__...

Barf.  Fortunately, no implementor in his right mind is going to do this,
because it will make either -D or __STDC__ (your choice) almost useless.
Well, perhaps that is a *slightly* over-strong statement, but it's still
close to true.  -Dfoo=bar is often used to supply things like configuration
parameters without having to modify source.  People who use it in this
manner are essentially saying "prepend '#define foo bar' to the file,
taking the result as the program to be compiled", not "change the
implementation by predefining foo".  Compiler implementors who insist
that any use of -D is an implementation change will be lynched by software
writers whose packages use -D as part of the program and who want __STDC__
to be a tool rather than a millstone around their necks.

(Speaking as such a software writer, I do *not* consider the suggestion
of doing an explicit -D__STDC__=1 every time to be helpful.  I don't
have to do this after every #define, I don't want to have to do it after
every -D in my Makefile either.)

Unfortunately, it is just a little bit hard for the implementation to
intuit whether a particular predefinition is one or the other.  There
really ought to be a way for a program to specify that a predefinition
of a particular identifier is expected.
-- 
"God willing, we will return." |     Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry at zoo.toronto.edu