Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!ucsd!ames!pacbell!att!cbnewsl!dfp From: dfp@cbnewsl.ATT.COM (david.f.prosser) Newsgroups: comp.std.c Subject: Re: Reserved names in ANSI C Message-ID: <919@cbnewsl.ATT.COM> Date: 26 Jun 89 14:30:53 GMT References: <13680@haddock.ima.isc.com> <1598@cbnewsh.ATT.COM> <875@cbnewsl.ATT.COM> <316@mountn.dec.com> <884@cbnewsl.ATT.COM> <321@mountn.dec.com> Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser) Organization: AT&T Bell Laboratories Lines: 71 In article <321@mountn.dec.com> minow@mountn.UUCP (Martin Minow) writes: >In article <884@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes: >> >>>When I complained about this in one of the public reviews, I was told that >>>this was for "Posix compliance." >["this" refers to namespace pollution"] >> >>I don't know what particular item you are referring to here, and the answer >>of "Posix compliance" cannot by itself be an X3J11 motivation. > >From X3J11/87-207, page 17 (responses to first public comments): > > Summary of issues: Add leading underscores to names in > > Committee Response: This proposal would invalidate too much existing > source code. > > Many of these names were chosen to agree with other standards. Despite > a number of comments on this issue, the Committee stands by its decision > to adhere to the names specified in both the /usr/group Standard and > IEEE Std 1003.1 (POSIX). > >------ Note that this does not state that these names were chosen for POSIX conformance, but that these names were based on existing implementations, and in the interests of existing code. The same motivations were present for both /usr/group and POSIX, so the name choices were made, where ever possible, to agree with other (to be) standards. > >The committee *could* have defined all library names using leading >underscores and included a suggestion that vendors supply a >or similar to map Ansi names into "existing practice." (This may also >solve the 6-character monospace problem). Yes, the Committee *could* have done so, but then they would have been clearly in violation of its "codify existing practice" foundation. The above proposal to rename the existing names in with a leading underscrore would have, in practice, only *increased* the number of reserved names! Since *all* current implementations would need to add an entire set of new names, and since they could not cause their customers' code to fail to compile, all the old names would need to be still available. Requiring even the inclusion of a new header would have been unworkable. Moreover, any program that wanted to work with both old and new compilers would be, at best, only slightly unreadable since for every library function, there would need to be some macro version to map the name between one version or another. The Committee received a number of similar requests. In a *perfect* world, there would have been no doubt that the Committee would have caused the set of reserved names to be obviously distinct from programmer-defined names, but the years of existing practice made that approach impossible. What the Committee did was come to a workable compromise: Implementations are required to prevent any names other than those that are standardized to be forced on a strictly conforming program while programmers need to remember that certain names are reserved. The programmer's job is not as bad as one makes it out to be since a program's use of a reserved name (that works) on a particular implementation still produces a conforming program. It is only those programs striving for strict conformance that must be especially careful. This is not an attempt to say that programmers should not try for strict conformance, but just an acknowledgement that most programs happen to rely on nonportable features or nonstandard library functions. > >Martin Minow >minow%thundr.dec@decwrl.dec.com Dave Prosser ...not an official X3J11 answer...