bill@proxftl.UUCP (T. William Wells) (05/25/88)
In article <4085@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: > In article <176@proxftl.UUCP> bill@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.
karl@haddock.ISC.COM (Karl Heuer) (05/25/88)
In article <211@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: >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. In such case, an ANSI compiler is also likely to silently do what you expect, with the same level of guarantee: if you know enough about the internals to know that it's safe, then it's safe. >And my main complaint is not with the fact that names are reserved but with >the fact that SO many of them are. I agree that namespace pollution is a problem. Fortunately, it seems that the macro names are reserved only when the corresponding header is included. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
jss@hector.UUCP (Jerry Schwarz) (05/27/88)
In article <211@proxftl.UUCP> bill@proxftl.UUCP writes: > >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. > Many begining C programmers have written something like void write(n) int n ; { printf("n=%d\n",n) ; } In the past this has failed in almost all (maybe all) UNIX implementations of C. ANSI has decreed that this function work. Jerry Schwarz Bell Labs, Murray Hill