🚀 go-pugleaf

In article <9167@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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