Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!mailrus!ncar!tank!shamash!com50!jhereg!mark
From: mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn)
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-conforming ANSI C compilers
Message-ID: <406@jhereg.Jhereg.MN.ORG>
Date: 21 Jan 89 18:47:11 GMT
References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <9422@smoke.BRL.MIL> <2820@ficc.uu.net> <320@microsoft.UUCP>
Reply-To: mark@jhereg.MN.ORG (Mark H. Colburn)
Organization: Minnetech Consulting, Inc., St. Paul MN
Lines: 28

In article <320@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:
>Basically, this tells you the compiler won't barf on prototypes or
>forward struct references or const or volatile or unary + or ...
>or # and ## or defined() or any such ANSIism.  You still have to worry
>about finding the right headers and strrchr and all the library mess
>that currently exists.  The compiler comes halfway.

The problem that others (such as Doug Gwyn) are looking at is does it
really understand all of the things that you mentioned, such as function
prototypes, #, ##, unary plus, etc.?  What if it just understands function
prototypes, const, volatile and forward structure references?  I would bet
there there are going to be vendors out there that decide that that is
going to be good enough to define __STDC__.  As a developer, I'm going to
be very annoyed when my "maximally portable application" is compiled on 
their system and fails due to a syntax error when it encounters a unary
plus.

Basically, what I think (I won't speak for any others) is that the only
system that is close enough to the standard to define __STDC__ is one that
is fully conformant.  When I was in high-school I had a science teacher who,
when we asked how close to the correct answer we had to be, would respond: 
"How close do you have to be to kiss your girlfriend?"  I think that it
follows here too...

-- 
Mark H. Colburn                  "They didn't understand a different kind of 
Minnetech Consulting, Inc.        smack was needed, than the back of a hand, 
mark@jhereg.mn.org                something else was always needed."