Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!hplabs!hpfcdc!rml From: rml@hpfcdc.HP.COM (Bob Lenk) Newsgroups: comp.std.c Subject: Re: Re: __STDC__ and non-conforming ANSI C compilers Message-ID: <12040006@hpfcdc.HP.COM> Date: 20 Jan 89 00:20:20 GMT References: <898@ubu.warwick.UUCP> Organization: HP Ft. Collins, Co. Lines: 168 > The problem is NOT in the __STDC__==1 (or ==2, etc.) domain; > it's in the unstandardized domain, for which __STDC__ simply > does not help I agree, but I'd go one step further. In practice the X3J11 work has made the situation where __STDC__ is not defined worse. Before X3J11 there was certainly chaos, but there were various assumptions that generally held. As X3J11 has defined new features that violate those assumptions and implementors provide them piece-meal that chaos has gotten more complex. This is especially true if __STDC__ can't be defined whenever the namespace is polluted, because that's such a common and useful situation which won't go away with pre-ANSI compilers. > >Now one form of "strict ANSI non-compliance" (i.e., the negation of > >"strict ANSI compliance") that could be useful would be that exhibited > >by an implementation that conforms to ANSI C except for POSIX items that > >might get in the way. > > There weren't supposed to be any of these! As inheritor of the role > of 1003.1/X3J11 liaison, I'm painfully aware of that; read on... > > 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. It seems to me that a defining non-ANSI symbols results in "strict ANSI non-compliance" whether or not a separate compilation mode was used. The only ways for 1003.1 to have stayed within the strict ANSI bounds would have to move things like fileno() out of or to rename them to something like __fileno(). Since the 1003.1 goals (like X3J11's) included following existing practice, this wasn't realistic. At this point 1003.1 seems to be in a "Catch 22" situation. Folks want something specified by the compiler rather than the application, but then they claim that a compiler that usurps the namespace must not define __STDC__. > _POSIX_SOURCE, a late invention to try to resolve the name space > conflicts in standard headers that define things for both ANSI C and > POSIX, was specified backward from what X3J11 had recommended; I don't recall any recommendation from X3J11. What was it? > _POSIX_SOURCE, specified as being supplied by the > APPLICATION, not the implementation, was specified as turning OFF > POSIX-permitted extensions, but what was really needed was a way to > turn ON ANSI C-prohibited extensions, Where do you read this? I see in section 2.8.2.1: If there are no feature test macros present in a program, only the set of symbols defined by the C Standard shall be present. For each feature test macro present, only the symbols specified by that feature test macro plus those of the C Standard shall be defined when a header is included. In other words, _POSIX_SOURCE (a feature test macro) does turn on definition of symbols not defined by the C Standard (ANSI C-prohibited extensions). Perhaps you are thinking of section 2.8.2.2. First of all, that section only applies to common usage C, and thus has no bearing on ANSI C environments. Second, it defines only the state when _POSIX_SOURCE is defined, not the state when it is not defined (which is outside the scope of any standard) and thus not whether _POSIX_SOURCE has an additive effect, a subtractive effect, or any effect at all. > and in any event the vendors don't want to tell their customers > to #define _POSIX_SOURCE in order for their existing code to compile. Vendors who want their customers' existing code to compile unchanged will provide backward-compatible compilers and environments to permit that. The P1003.1 working group did not believe that many existing programs would conform to the new standard with zero change. > The simplest solution would have been: > cc # backward-compatible sloppy UNIX mess version > acc # ANSI-conforming version > pcc # POSIX- and ANSI-conforming version > fcc # like "pcc" but with extra ANSI-prohibited stuff. If this is still under the assumption that 1003.1 preserved strict ANSI C conformance, I don't see why pcc would be needed at all; it could be synonymous with acc. If we accept that (and the analogous relations with other, future standards) as impossible, what happens when 1003.2 adds popen() to and 1003.4 adds symbols to 1003.1 headers like and ? Do we add new commands like: p12cc # 1003.1 and 1003.2 conforming p2cc # 1003.2 conforming p14cc # 1003.1 and 1003.4 conforming p124cc # 1003.1, 1003.2, and 1003.4 conforming The "feature test macro" approach introduced in 1003.1 seems to handle this much more cleanly, with N names rather than up to 2**N names for N standards. > cc __STDC__ not defined > acc __STDC__==1 > pcc __STDC__==1 > fcc __STDC__ not defined I don't understand this at all (assuming pcc is needed at all - see above). From the ANSI C perspective, pcc and fcc should be identical; they are ANSI C with a polluted namespace. The fact that pcc has its pollution defined by a clear standard while fcc doesn't makes no difference here. Practically I think that ANSI C should explicitly permit the namespace to be used in any way explicitly or implicitly specified by the user, as long as there is a clearly documented way to get a completely clean namespace. Thus invoking pcc or fcc or "acc -DFOO" as defined here should leave __STDC__ == 1, as long as the effect on the namespace is clearly documented. As others have stated, the predefine is not at all useful in dealing with namespace pollution, beyond (perhaps): #if !__STDC__ #error #endif > >The best I see that could be done here is to make a strong > >recommendation that POSIX vendors define > >__ANSI_C_EXCEPT_FOR_POSIX_STUFF__ (or some other specified name) to > >match what __STDC__ would have been defined as had the "allow POSIX > >stuff" flag not been given to the compiler. > > Practically ANY de facto standard not involving __STDC__ would be fine > so far as I'm concerned. As it stands, we have no satisfactory > solution. I'm not sure what problem is being addressed here, but I think there are solutions to all the real problems except one. If an application is compiled with the straight ANSI compiler, it can test __STDC__ for whatever it is interested in. It can define _POSIX_SOURCE itself if it wants POSIX symbols. If it wants to know whether POSIX is supported, it can then test _POSIX_VERSION from (although the include of may fail on a non-POSIX system, I doubt this would be an issue to any application that cared about this question). The only unsolved problem is whether the compiler which (at least effectively) pre-defines _POSIX_SOURCE can define __STDC__. I repeat that from a practical perspective I think it should, as long as there's a way to get a truly clean namespace. __ANSI_C_EXCEPT_FOR_POSIX_STUFF__ falls into exactly the same trap as the different compiler names, when N standards enter the picture there are up to 2**N possibly meaningful symbols. We could add one symbol like __ANSI_C_EXCEPT_POSSIBLE_NAMESPACE_ADDITIONS_AS_REQUESTED_IN_INVOCATION__. My point is that such a symbol seems far more useful than the strict __STDC__, and it makes more sense to make that the meaning of __STDC__. 1003.1 could have addressed this by requiring one of two symbols like _POSIX_STANDARD_C or _POSIX_COMMON_C to be defined, but that really seems to be redundant with the purpose of __STDC__, and in the scope of a language standard rather than an OS standard. > It's really unfortunate that 1003.1 didn't straighten out more of the > name space problems historical UNIX has had. I think it's unfortunate that X3J11 didn't consider that the C library is (at least in some valid cases) a foundation upon which other environments build rather than a complete environment, and thus didn't allow for graceful additions to the namespace consistent with existing practice. If they had addressed the problem sufficently and explained the solution clearly, there wouldn't be all this debate about how 1003.1, Microsoft, AT&T, et. al. are dealing with the situation. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com