Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers
Keywords: ANSI C, __STDC__
Message-ID: <9200@smoke.BRL.MIL>
Date: 16 Dec 88 04:57:24 GMT
References: <3236@pegasus.ATT.COM> <9167@smoke.BRL.MIL> <721@auspex.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 44

In article <721@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
>For instance, consider a program written for a POSIX environment, so
>that it might not compile in "strict ANSI C" mode, but written so that
>it can use function prototypes if they're present?  Should __STDC__ be
>defined by the compiler running in "ANSI C plus extensions" mode, so
>that the code can use "__STDC__" to determine whether function
>prototypes, or "#" and "##", or... are supported?

The answer is still, no, if the implementation environment does
not fully conform to the standard then it should not set __STDC__.

The reason is this:  The C standard has no "levels" or "options".
Standard conformance is a Boolean attribute, like pregnancy.
If the programmer's test for standard conformance "#if __STDC__"
is to be reliably used, it must mean something definite.  When a
vendor elects to set __STDC__ even though the environment is
not conforming with respect to feature X, there is no way he can
know whether or not the programmer relying on the __STDC__ flag
will have his code broken because of its reliance on standard
behavior with respect to feature X.  How do you know that the
only use the program will make of __STDC__ is for the grossly
different syntactic features (prototypes, pasting, etc.)?  The
answer is, although very likely most uses of __STDC__ will be
for that purpose, by no means all uses will be.  So if __STDC__
is to be 100% reliable it must mean exactly what X3J11 says it
means, and must not be defined otherwise (something that the
standard cannot require, but was thought to be self-evident).

What Jerry seems to want is to "borrow" some of the guarantees
that __STDC__ makes for use in a non standard-conforming
environment also.  Unfortunately for his purpose, __STDC__
promises compliance with the standard, not existence of some
specific subset of ANSI C-like features.

In the case where !__STDC__, things are exactly as messed-up
as always with regard to what features might exist and how
polluted the name space is.  But then, we really intend for
C programming to evolve so that most code is fully
standard conforming; __STDC__  gives the programmer a way to
code for both standard and "other" environments, if he has to
cope with both.  Obviously the "other" environment is not
well defined; that's why we drew up a standard!  Trying to
make a piece of the standard fix long-standing problems in
the "other" environment is not only hopeless, it can damage
the utility of the standard.