__STDC__ and non-strictly conforming ANSI C compilers

[Doug Gwyn]

In article <11002 at ulysses.homer.nj.att.com> jss at hector.UUCP (Jerry Schwarz) writes:
>If a vendor offers both a conforming ANSI and variations, it is
>reasonable  that a version containing extensions (e.g. new keywords)
>also have __STDC__ set.

I totally disagree.  Invent your own symbol for your non standard-
conforming implementation; don't overload the meaning of __STDC__.
AT&T has been guilty of FAR too many overloadings in C and UNIX
already.  I know you have heard of the concept of orthogonality;
how about applying it at least HERE where the intention is
unambiguous.

>Doug would seem to encourage code such as
>	#ifdef __STDC__
>		char* p ;
>	#else
>		near char* p ;
>	#endif

No, in fact I fully intend to be able to write:
	#if __STDC__
		#if _BRAIN_DAMAGED
			typedef __far void *far;
		#else
			typedef void *far;
		#endif
		extern far gcalloc(size_t size, far *handle);
	#else
	#	if _BRAIN_DAMAGED
			extern far char *gcalloc();
	#	else
			extern char *gcalloc();
	#	endif
	#endif
Note that I expect __STDC__ to not be true if "far" is defined
as a keyword, because that is not standard-conforming.

>The use of "near" ought to be conditioned on some positive assertion about the compilation system,
>not merely that it isn't conforming.

Quite true and quite obvious.

But __STDC__ must MEAN something or it's not reliably useful.  What would
you have it mean, if not "the implementation conforms with the standard"?

"__STDC__" belongs to X3J11.  We should have made it a trademark,
I suppose.  Don't play games with it.