Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!decwrl!decvax!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: Mark Williams C
Message-ID: <13597@haddock.ima.isc.com>
Date: 5 Jun 89 22:48:14 GMT
References: <24094@agate.BERKELEY.EDU> <431fba10.14a1f@gtephx.UUCP> <13522@haddock.ima.isc.com> <118@elf115.uu.net>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 27

In article <118@elf115.uu.net> rec@elf115.uu.net (Roger Critchlow) writes:
>In article <13522@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes:
>> I think that, instead, I'll add the equivalent of [#undef __STDC__]
>
>Sorry, you aren't allowed to #undef __STDC__ [according to the Standard].

A non-conforming compiler is not bound by the Standard anyway; it knows no law
save that of the marketplace.  In any case, when I said "the equivalent of", I
meant to include measures as drastic as binary-patching the compiler.

>> until someone decides just what __STDC__==0 is supposed to mean.
>
>[It apparently means that the preprocessor agrees with the ANSI specs]

I'm perfectly willing for it to mean that, but there has to be a consensus, if
not a formal standard.  Should I be using #ifdef when I want to test the
preprocessor, and #if when I want to test any other part of the compiler?
What if some other vendor uses __STDC__==0 to mean that their compiler
understands prototypes but not token-pasting?

>The Rationale suggested that: "This macro should be of use in the transition
>toward conformance with the Standard."

It's certainly of such use to users.  I doubt that it was intended to be used
transitionally by implementors.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint