Path: utzoo!attcan!uunet!lll-winken!ames!ncar!noao!arizona!mike
From: mike@arizona.edu (Mike Coffin)
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <8731@megaron.arizona.edu>
Date: 16 Jan 89 20:45:40 GMT
References: <9391@smoke.BRL.MIL>
Organization: U of Arizona CS Dept, Tucson
Lines: 30

From article <9391@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ):

> Problems arise when a non-conforming implementation thinks it is
> "close enough" and consequently defines __STDC__ (whether to 0 or 1
> is immaterial, since #ifdef __STDC__ is as likely to be used as the
> more paranoid #if __STDC__).

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?
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.
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?
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"?
-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2}!arizona!mike
Tucson, AZ  85721			(602)621-2858