Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!nrl-cmf!ukma!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-conforming ANSI C compilers
Keywords: ANSI C, SVr4 C
Message-ID: <9528@smoke.BRL.MIL>
Date: 28 Jan 89 05:02:16 GMT
References: <898@ubu.warwick.UUCP> <179@smsdpg.uu.net> <2525@pegasus.ATT.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 58

In article <2525@pegasus.ATT.COM> hansen@pegasus.ATT.COM (Tony L. Hansen) writes:
>    2)	Should it #define __STDC__ to be 1 by default?
>	First off, can it?

Of course it CAN; a nonconforming implementation can do anything it wants.
The question is, if it did, would that cause problems for applications?
The answer to that is definitely YES, it would.

>	Because it declares the extra functions, does that prevent it
>	from being a "fully conforming" ANSI C compiler?

Yes, it does.

If the visibility of the extra functions in the standard headers is
controlled by #ifdef _POSIX_SOURCE, on the other hand, then that is
not non-conforming, provided that _POSIX_SOURCE is not predefined by
the implementation.

>	Perhaps it SHOULD #define __STDC__ as 1 for both modes.

No, it shouldn't -- it definitely CAN matter to a strictly-conforming C
application, and if __STDC__ were 1 in such a non-conforming environment,
the application would have no way to determine that it is going to have a
problem.  I can accept __STDC__==0 for this, if we get near-universal
agreement on it, but not __STDC__==1 in ANY non-conforming environment,
no matter how "small" you consider the deviation to be.

For __STDC__==1, I consider that it suffices for practical purposes to
consider an implementation conforming if no strictly-conforming C program
can detect the difference.  Thus it wouldn't bother me for __STDC__ to be
set to 1 in an environment that provides upward-compatible extensions to
ANSI C.  Extra identifiers usurped from the application's name space do
not qualify as upward-compatible extensions.

>    3)	Is the SVr4 C compiler useful with this scheme?
>	My feeling is yes. I can use "#ifdef __STDC__" to fully differentiate
>	within my code between the old K&R C and new ANSI C syntaxes.

But syntax is not the only difference between those two C environments.

>By the way, I also reject the opinion that using -D when invoking an ANSI C
>compiler:
>	ansicc -Dxyz
>should suddenly cause __STDC__ to be undefined. (Sorry Doug, I think you're
>wrong here.)

I've since acknowledged that so long as the predefinition is being done
explicitly by the compiler user, not automatically by the compiler, it
would be most usefully considered as shorthand for editing all the
sources to temporarily "#define xyz 1".  Therefore that would not be
a "predefined" identifier in the ANSI C sense and would not require that
__STDC__ be changed from its normal value (1, 0, not defined, whatever).

On the other hand, if the compiler automatically predefines macros in
the application's reserved name space, or if it automatically predefines
macros in its own name space that cause other identifiers in the
application's name space to be usurped (e.g. _POSIX_SOURCE), then I
definitely want __STDC__ to NOT be set to 1.