Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.std.c Subject: Re: __STDC__ and non-conforming ANSI C compilers Message-ID: <883@auspex.UUCP> Date: 20 Jan 89 22:14:26 GMT References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <860@auspex.UUCP> <9422@smoke.BRL.MIL> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 88 >>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 )? >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 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 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....)