__STDC__ and non-strictly conforming ANSI C compilers

[sjs at ctt.bellcore.com]

In article <9187 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>
> Note that macros such as "near" can be defined (as "__near", for
> example) in any non-standard header, as well as under control of
> compiler options or a special non-ANSI, backward-compatible
> version of the cc command.  The constraints against pollution of
> the name space by implementations is a great advance in sanity
> and should be taken quite seriously.

Proposing that a compiler which conforms but for the addition of a few
keywords should define __STDC__ Jerry Schwarz asks:
>
> Does the answer depend on which of the following commands is used
> to invoke the non-conforming compiler?
> 
> 	xcc prog.c
> 	cc -extended prog.c
> 	cc -Dnear=__near prog.c

This is fine as long as there is SOME set of options, preferably the
default, under which "near", "far", and, for that matter, all other
identifiers are just that: identifiers.

The important question is whether a __STDC__ compiler can be counted
upon to compile strictly conforming programs.  The following fragment
illustrates my point:

	# include <stdlib.h>
	int near( int i, int j ) {
		return ( abs(i-j) < 10 );
	}

If "near" is a reserved keyword this will not compile even though it
is strictly conforming.  It is much better for ALL reserved words
introduced for extensions to begin with "_" and be mapped from
non-underscore values only when requested via an option or an include
file.

I'm not saying that vendors shouldn't add extensions, just that they
should do it without encroaching on the user's name space.  The X3J11
committee as provided perfectly good and totally painless way of doing
this without breaking programs.  Any compiler that doesn't bother to
do it that way shouldn't go around defining "__STDC__".

Probably by now most of us will avoid using the identifier "near" in
our programs because we know that it is a keyword in some compilers.
But this is a point of principle: what other identifiers must we now
worry about?  Perhaps we'll have to start a newsletter to keep track
of the identifiers to avoid because some vendor or another has
made it a keyword.

Let's not let compiler vendors undermine the good work of the
committee toward ending name space pollution.

Stan Switzer  sjs at ctt.bellcore.com