Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Machine specific predefined names
Message-ID: <7332@brl-smoke.ARPA>
Date: 24 Feb 88 14:24:02 GMT
References: <1988Feb17.115402.12739@light.uucp> <1988Feb21.015424.20436@utzoo.uucp> <17033@watmath.waterloo.edu> <2317@geac.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 55
Keywords: library names, clashes

In article <2317@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>  That the ANSI committee have chosen to ignore the problem is
>understandable, under the circumstances.  It is also an admission of
>incompetence and/or malfeasance, but that's a different discussion.

Far from ignoring the name space pollution problem, a conforming ANSI C
implementation is absolutely prohibited from infringing on the name
space reserved for the application, and a conforming application is
prohibited from preempting those names reserved for the implementation.

	"Each library function is declared in a header, whose
	contents are made available by the #include preprocessing
	directive.  The header declares a set of related functions,
	plus any necessary types and additional macros needed to
	facilitate their use.  Each header declares and defines only
	those identifiers listed in its associated section.  All
	external identifiers declared in any of the headers are
	reserved, whether or not the associated header is included.
	All external identifiers that begin with an underscore are
	reserved.  All other identifiers that begin with an
	underscore and either an upper-case letter or another
	underscore are reserved.  If the program defines an external
	identifier with the same name as a reserved external
	identifier, even in a semantically equivalent form, the
	behavior is undefined.

	The standard headers are:
		...
	If a file with the same name as one of the above < and >
	delimited sequences of characters, not provided as part of
	the implementation, is placed in any of the standard places
	for a source file to be included, the behavior is undefined."

Note that there is no prohibition against the implementation providing
additional external functions and data with identifiers NOT starting
with an underscore in its C library, so long as none of its ANSI C
support depends on them (because a conforming application is allowed
to use those names for its own external identifiers with different
semantics).  Additional system-specific headers can also be provided.
Note also that certain ranges of identifiers, such as SIG*, are
reserved for the implementation by the proposed standard.  Thus, a
conforming implementation must avoid using identifiers such as
	fopen	SIGMA	errno
for purposes other than those specified by the standard.  (SIGMA is
safe to use, however, if <signal.h> is not included.)

On the other hand, the proposed IEEE 1003.1, even with an attempt at
accommodating concerns expressed by X3J11 and at least two balloting
members concerning this issue, still does not adequately address the
problem.

What is this about "an admission of incompetence and/or malfeasance"?
Whose admission -- yours?

You know, it would be nice if people would at least READ the proposed
standard before publicly proclaiming what they think is wrong with it.