Newsgroups: comp.std.c
Path: utzoo!utgpu!jarvis.csri.toronto.edu!ephemeral.ai.toronto.edu!bradb
From: bradb@ai.toronto.edu (Brad Brown)
Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers
Message-ID: <88Dec14.212142est.10862@ephemeral.ai.toronto.edu>
Keywords: ANSI C, __STDC__
Organization: Department of Computer Science, University of Toronto
References: <3236@pegasus.ATT.COM>
Date: Wed, 14 Dec 88 21:21:36 EST

In article <3236@pegasus.ATT.COM> hansen@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@ai.toronto.edu