Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!decwrl!shlump.dec.com!mountn.dec.com!minow From: minow@mountn.dec.com (Martin Minow) Newsgroups: comp.std.c Subject: Re: Reserved names in ANSI C Message-ID: <321@mountn.dec.com> Date: 22 Jun 89 19:18:56 GMT References: <13680@haddock.ima.isc.com> <1598@cbnewsh.ATT.COM> <875@cbnewsl.ATT.COM> <316@mountn.dec.com> <884@cbnewsl.ATT.COM> Reply-To: minow@mountn.UUCP (Martin Minow) Organization: Digital Equipment Corporation Lines: 36 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). ------ 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). I continue to have difficulty writing transportable programs when well-meaning implementors use useful words (such as "line" in one vendor's Macintosh C library). Since there is only one Ansi Standard and, hopefully, many people writing code to that standard, I wish the Committee had found way to prevent the C-implementation namespace from growing without bounds. Martin Minow minow%thundr.dec@decwrl.dec.com