Reserved names in ANSI C

[david.f.prosser]

In article <321 at mountn.dec.com> minow at mountn.UUCP (Martin Minow) writes:
>In article <884 at cbnewsl.ATT.COM> dfp at 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 <limits.h>
>
>  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 <posix.h>
>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 <limits.h> 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 at decwrl.dec.com

Dave Prosser	...not an official X3J11 answer...