__STDC__ and non-strictly conforming ANSI C compilers

[Brad Brown]

In article <3236 at pegasus.ATT.COM> hansen at pegasus.att.com writes:
>What do people think a compiler should do with __STDC__ if it is not
>strictly conforming? ...
>
>I've seen three solutions so far in as many compilers which plan on being
>ANSI C compatible. ...
>
>    1)	Only the strictly conforming flavor will have __STDC__ defined, and
>	then to "1".
>
>    2)	In non-strictly conforming mode, __STDC__ will be defined but will
>	have a value of "0".
>
>    3)	In all modes, __STDC__ will be defined with the value of "1".
>
>Which choice should be the correct one? Should the Rationale say something
>about it? Is there a 4th choice not listed above?

What about having all strictly conforming compilers, including those
with extentions, define __STDC__ -- personally I don't care much what
the value is, and I think most people would not bother to check.  THEN,
when a compiler has extentions, define a couple of new #defines, perhaps
minimally just __STDCEXT__ to indicate that extentions exist.

In most compilers I have seen on the IBM PC, there are standard #defines
for the memory model that the program is currently being compiled for
and for the specific model of compiler.  I guess this is as close as you
could come to defining what the extention flags mean (they have to be
implementation-specific because there's always going to be some new
machine with some new feature) but maybe the standard could say you have
to have a __STDCEXT__ when extentions are present...

					(-:  Brad Brown  :-)
					bradb at ai.toronto.edu