Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!gatech!rutgers!bellcore!jcricket!sjs From: sjs@jcricket.ctt.bellcore.com (Stan Switzer) Newsgroups: comp.std.c Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers Keywords: ANSI C, __STDC__ Message-ID: <12643@bellcore.bellcore.com> Date: 14 Dec 88 14:39:53 GMT References: <3236@pegasus.ATT.COM> <9167@smoke.BRL.MIL> Sender: news@bellcore.bellcore.com Reply-To: sjs@sjs@ctt.bellcore.com (Stan Switzer) Organization: Computer Technology Transfer, Bellcore Lines: 41 In article <9167@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: > In article <3236@pegasus.ATT.COM> hansen@pegasus.att.com writes: > >What do people think a compiler should do with __STDC__ if it is not > >strictly conforming? > > Obviously the actual standard cannot constrain nonconforming > implementations. However, any implementation that defines > __STDC__ at all in a non-conforming mode is doing a severe > disservice to the C programming community. ... > > Please don't define __STDC__ at all for non standard- > conforming implementations, even if they provide a lot of > so-called "ANSI C" features. ... I certainly agree with Doug here, and I hope that the vendor community goes along with him in this regard. Back to some of the original examples though: A compiler that accepts identifiers longer than 31 characters or even arbitrarily long identifiers is still a conforming compiler. It is only those which do not accept at least 31 characters uniqueness (within a compilation unit) which do not conform. A compiler that reserves "near" and "far" as keywords is no-way no-how a conforming compiler. Period. IF such "features" are required (and I'll admit that if you are stuck writing code that has to be aware of segments it is nice to have them) then they should go by the names "_near" or "_far" which is in the vendor's reserved name space. Perhaps there could be compiler options (-Dfar=_far) which map "near" and "far" onto the actual keywords. The committee has gone to great lengths to make strictly-conforming programs highly portable. It'd be a shame if the vendors were to undermine that effort by adding gratuitous "extensions" that break these programs. I, for one, am looking forward to that day when it will be possible to write interesting and portable C programs that are not sprinkled throughout with "#ifdef" directives. But in the interim, I hope that when I say "#ifdef __STDC__" I get no ugly surprises. Stan Switzer sjs@ctt.bellcore.com