Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Mark Williams C
Message-ID: <10334@smoke.BRL.MIL>
Date: 28 May 89 02:38:19 GMT
References: <24094@agate.BERKELEY.EDU> <431fba10.14a1f@gtephx.UUCP> <8137@boring.cwi.nl> <8530@chinet.chi.il.us> <13475@haddock.ima.isc.com> <1000@twwells.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <1000@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
>The ANSI standard applies only to implementations and programs
>claiming conformance to it. Who should care what others do?

Developers of applications care, that's who.  We need a reliable way
of testing for a Standard-conforming implementation.  __STDC__ was
supposed to be the way.

>If you are writing programs that have to check the implementation for
>conformance, you had just better only check for __STD__ == 1.

Unfortunately, vendors of non Standard-conforming C implementations
have already been defining __STDC__ as everything under the sun,
including 1.  This does piss me off...

We went through this discussion a few months ago.  The inevitable
outcome seems to be that, given the lack of vendor restraint
necessary to make __STDC__ serve its intended purpose, application
code has to provide its own arrangements for such configuration
information.  For example, my standard configuration header <std.h>
now includes an appropriate definition of my own macro STD_C which
I use the way that __STDC__ was intended to be used.