Reserved names in X3J11 (was Re: Appreciation for ANSI C committee)

T. William Wells bill at proxftl.UUCP
Wed May 25 04:38:53 AEST 1988


In article <4085 at haddock.ISC.COM>, karl at haddock.ISC.COM (Karl Heuer) writes:
> In article <176 at proxftl.UUCP> bill at proxftl.UUCP (T. William Wells) writes:
> >It is certainly the case that some of the things they [X3J11] are doing
> >are really screwed up [e.g.] the reserved library names
>
> Reserved library names are current practice.  ("Reserved" meaning that you
> might be able to get away with redefining them, but it's not portable.)  You
> can't blame X3J11 for that one.

Almost.  They are not quite reserved in the same sense that X3J11
would have them.  And my main complaint is not with the fact that
names are reserved but with the fact that SO many of them are.

Specifically, if you define a function whose name matches a
function name in one of the more esoteric libraries and you do
not use something from the same library, all of the C compilers
that I am familiar with will not give you grief.

If I had my 'druthers, I would make the standard define a VERY
small library of routines whose names are reserved and a set of
libraries whose names become reserved if you use their associated
include file or refer to any of the functions contained in the
library.

Another issue related to the library name issue (and which was
also on my mind when I wrote the quoted passage) is the general
name space pollution problem.  If you want to write a really
portable program, one which is unlikely to cause problems now or
in the future, there are a whole bunch of names you should steer
clear of.  Like names beginning with a E.  Or names beginning
with str.  Or names beginning with ....  But you get the idea.

If not then I have already made my point: you mean you do not
know which names the implementer can define while remaining
conforming?  And you do not happen to remember which names could
become reserved sometime in the future?

A goal which I think should be kept in mind when designing any
programming language is: what you do not know and have no reason
to know should not hurt you.  The bigger the language, the more
important this idea becomes.  X3J11 has made C bigger.  It ought
not to also have made it more difficult to use.

Sigh.



More information about the Comp.lang.c mailing list