__STDC__ and non-conforming ANSI C compilers

[Guy Harris]

 >>if you stick a "#else" in there at that level, what goes between it
 >>and "#endif"?
 >
 >Whatever is already going on in the existing pre-ANSI C implementation.
 >The reason we needed a standard was that this was pretty much a random
 >approximation to what K&R seemed to be saying, plus various additional
 >inventions done wildly differently by different implementors.

Yes, I know that's why a standard was needed.  The problem is that there
is no "the" existing pre-ANSI C implementation, so you have to have some
particular target or targets in mind when you write the code that goes
there.  I presume you are thinking of situations where that is the case
(or where you're willing to deal with new targets as you come across
them, as in your later example of <varargs.h>)?

>the bottom line is that a PARANOID programmer is advised to write
>	#ifdef __STDC__
>	#if __STDC__ > 0
>	#define MY_STDC_INDICATOR 1
>	#endif
>	#endif
>then use MY_STDC_INDICATOR instead of __STDC__,

Or, as Peter da Silva pointed out, to write

	#ifndef __STDC__
	#define	__STDC__ 0
	#endif

then just use "#if __STDC__".

>The main problem seems to be that vendors want to include their old
>extra UNIX cruft in <stdio.h> without requiring their customers to
>use a different form of compilation from the ANSI C mode.  Even 1003.1
>wants to do this.

By "extra UNIX cruft", do you mean POSIX stuff (e.g., "fdopen" and
"fileno"), or stuff over and above that?

>What I would have for the two names known to the programmer in each
>of the four cases are:
>	cc	__STDC__ not defined
>	acc	__STDC__==1
>	pcc	__STDC__==1

In other words, even though including <stdio.h> when compiling in
"POSIX+ANSI" mode would cause "fileno" and "fdopen" to be declared if
functions, or defined if macros, __STDC__ should be defined anyway? (If
it neither defines nor declares them, I don't see how "acc" differs from
"pcc"....)  I agree that this is OK, but I was under the impression that
it would violate the letter of the standard.

>	fcc	__STDC__ not defined
>
>I think AT&T has in mind the use of __STDC__==0 in the "fcc" case
>instead of coming up with their own secret symbols, and merging
>"cc" and "fcc" together into one case, and "acc" and "pcc" into a
>second case.

No, I think their intent is that:

	the moral equivalent of "cc" be "traditional C + whatever ANSI
	C things don't break traditional C + UNIX" - i.e.,
	unsignedness-preserving conversions, Reiserisms, etc.;

	the moral equivalent of "acc" be STRICT ANSI C - no "fdopen" nor
	"fileno", for example;

	the moral equivalents of "pcc" and "fcc" perhaps be merged into
	one, leaving it up to the user to distinguish POSIX-only from S5R4.

__STDC__ would (according to other postings reporting from the S5R4
Developer's Conferences - my memory of AT&T's requirements documents
gives out at this point) be defined as 0 in the "moral equivalent of
'cc'" case; I don't know if it'd be defined as 0 or 1 in the "moral
equivalents of 'pcc' and 'fcc' case", but I think the intent may be to
define it as 0, so that "#if !__STDC__" would protect all extensions
that chew up the ANSI C namespace.

>It's really unfortunate that 1003.1 didn't straighten out more of the
>name space problems historical UNIX has had.

How would you suggest it have done that?  (I don't think a solution of
"rename 'fdopen' and 'fileno'" would have been accepted by consensus. 
*I'd* certainly have been ticked had they done that; had they done that,
I would have insisted that they delete the "IX" from "POSIX", so that
they don't pollute the namespace of UNIX-flavored systems....)