Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: __STDC__ and non-strictly conforming ANSI C compilers
Keywords: ANSI C, __STDC__
Message-ID: <9198@smoke.BRL.MIL>
Date: 16 Dec 88 04:23:34 GMT
References: <3236@pegasus.ATT.COM> <9167@smoke.BRL.MIL> <11002@ulysses.homer.nj.att.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 46

In article <11002@ulysses.homer.nj.att.com> jss@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.