Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Reserved names in ANSI C
Message-ID: <10427@smoke.BRL.MIL>
Date: 21 Jun 89 21:11:59 GMT
References: <GEOFF.89Jun11231924@onyx.cs.warwick.ac.uk> <13680@haddock.ima.isc.com> <1598@cbnewsh.ATT.COM> <1989Jun21.090428.9636@twwells.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 39

In article <1989Jun21.090428.9636@twwells.com> bill@twwells.com (T. William Wells) writes:
>	E[0-9A-Z].*     macros in errno.h
>	is[a-z].*       externals, ctype.h
>	to[a-z].*       externals, ctype.h
>	LC_[A-Z].*      macros in locale.h
>	<func>f         <func> is any function defined in math.h
>	<func>l         <func> is any function defined in math.h
>	SIG[A-Z].*      macros in signal.h
>	SIG_[A-Z].*     macros in signal.h
>	str[a-z].*      externals, stdlib.h and string.h
>	mem[a-z].*      externals, string.h
>	wcs[a-z].*      externals, string.h

The E* names are reserved only if <errno.h> is included.  Similarly,
the LC_* names are reserved only if <locale.h> is included, and SIG*
names are reserved only if <signal.h> is included.  The function
names mentioned are (of necessity) reserved whether or not headers
are included.

>No doubt there are others scattered throughout the spec, but I
>haven't the will to go hunting for them.

No doubt?  Section 4.1.2.1 covers this issue; it mentions the 4.13
sections, _* names, etc.  "No other identifiers are reserved."

>Can you say "name space pollution"?

X3J11 didn't cause C name space pollution; to the contrary, it has
finally been brought under control.  The majority of the above name
classes were already "polluted" by existing practice, so they were
identified and the existing practice allowed to continue but within
the newly established limits.  Certainly, application developers
need to know these limits so they can stay on the other side of the
fence.  At least they have now been allowed to stake out territory
of their own.

If one were designing a C-like language from scratch today, in the
light of past experience it would be wise to introduce some sort of
"package" concept and adhere strictly to it.