Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <9405@smoke.BRL.MIL>
Date: 17 Jan 89 16:47:41 GMT
References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 58

In article <8731@megaron.arizona.edu> mike@arizona.edu (Mike Coffin) writes:
>1) If the intent was that only conforming compilers define __STDC__,
>   why is this loophole in the standard?  I.e., why does the standard
>   specify "1" as THE value for __STDC__?  Is it too late to change
>   things, if the wording does not correspond to the intent?

The wording does reflect the intent.  Rather than "__STDC__ is defined
as some nebulous thing", the proposed Standard says what it is defined
as, for this edition of the Standard.  (Presumably it would have other
values in revisions of the Standard.)

The Standard is obviously unable to specify anything about __STDC__
for a non-conforming implementation, because by definition such
implementations do not obey the Standard!

>2) Why is #ifdef "as likely to be used" as #if?  The latter is shorter
>   and tests for exactly what the standard specifies; the former is
>   longer and doesn't.  It seems to me that using #ifdef for this
>   purpose is just a bug, pure and simple.

Either form tests "true" with a standard-conforming implementation.
It SHOULD be the case that either form tests "false" with non-conforming
implementations.  However, there are known non-conforming implementations
that complain about "#if __STDC__" unless __STDC__ is defined as a
numeric expression (which it isn't, in those implementations).  Therefore
a programmer may prefer "#ifdef __STDC__" to distinguish between Standard-
conforming and non-conforming environments.  But is non-conforming
environments decide to define __STDC__, this doesn't work either.

>3) I suppose there is a need to determine whether the compiler is
>   exactly "conforming", although I'm not sure what you would do if it
>   wasn't.  But the need is far more pressing for a flag that answers
>   the question "is this a K&R compiler or an ANSI compiler?"  How do
>   we tell the difference between a K&R compiler and an ANSI compiler
>   that is invoked in such a way that it's nonconforming?  (E.g., 
>   "cc -DFOO".)  Does the standard say anything about this?  Shouldn't 
>   we adopt some convention before we have chaos?

I don't know what you mean by a "K&R compiler".  Existing UNIX compilers
do not conform to either K&R or the pANS.  From my perspective, the MOST
important distinction is between C environments that follow the Standard
(in which case I know EXACTLY what to expect) and ones that don't.  The
latter category is just as messed up as it has ALWAYS been, and no
single test is sufficient to untangle THAT mess.  However, we should
adhere very strictly to the use of __STDC__ to distinguish between the
well-defined case and the myriad of random implementations.  Dragging
__STDC__ into the morass merely ruins its utility; it doesn't help the
user of an uncontrolled C environment to determine anything reliable.

>4) In view of the fact that "#ifdef __STDC__" doesn't tell us
>   anything, according to the standard (as I understand it), what is
>   wrong with using it to indicate "rough ANSI compliance"?

I've explained that above.  "Rough ANSI compliance" is meaningless
and useless to the portable application programmer.  "Strict ANSI
compliance", on the other hand, is a meaningful notion of considerable
utility to the programmer.  In order for it to HAVE this utility,
though, we need the symbol __STDC__ reserved for making the distinction.