Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!ig!arizona!mike
From: mike@arizona.edu (Mike Coffin)
Newsgroups: comp.std.c
Subject: : Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <8809@megaron.arizona.edu>
Date: 20 Jan 89 20:08:56 GMT
References: <9455@smoke.BRL.MIL>
Organization: U of Arizona CS Dept, Tucson
Lines: 27

Well, I'm bowing out.  It is clear to me that __STDC__ has no
practical application as far as porting code goes.  Compiler writers
that follow the letter of pANS will cause it to be undefined at the
slightest pretext, while others will set it to 1 if they consider
their nonconformance to be inconsequential.  Or maybe set it to 0,
or maybe "__ALMOST__," or "__PRETTY_CLOSE__."  Of course, there will
be as many definitions of "inconsequential" as there are compiler
writers.  (A really honest compiler writer would never turn on
__STDC__ until he was convinced his compiler had no bugs, I suppose.)

The practical significance is that if I actually put "#if __STDC__" in
a program, I would have to put "ifdef __almost_STDC__" in the #else
clause anyway.  And of course it would contain exactly the same code,
since I have no idea whether the compiler turned off __STDC__ for a
truly insignificant reason, or because this is really a FORTRAN
compiler named cc.

So, it's back to specifying compilation environments in the makefile.
I look forward to the day when there are no more "old" C compilers to
worry about, but I suppose by then we'll have a new standard to deal
with.


-- 
Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2}!arizona!mike
Tucson, AZ  85721			(602)621-2858