Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!hao!oddjob!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: MAJOR ANSI C FLAW (my opinion, of course) Message-ID: <6632@brl-smoke.ARPA> Date: Fri, 30-Oct-87 03:59:00 EST Article-I.D.: brl-smok.6632 Posted: Fri Oct 30 03:59:00 1987 Date-Received: Wed, 4-Nov-87 07:08:25 EST References: <10065@brl-adm.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 69 In article <10065@brl-adm.ARPA> vis!greg@bass.nosc.MIL writes: > From: Doug Gwyn > It's not clear what good it would do to send this to X3J11. >I ask that this proposal be considered by X3J11, and that others >who agree with me make the same request. After allowing for more >comments, it will be time to write the renaming program and to put >it into the public domain. After first making clear that I'm not speaking for X3J11 and want to encourage you to submit any constructive ideas about the draft Standard to X3J11 (which is not done by posting to this newsgroup or sending mail to X3J11 members other than Tom Plum, by the way), I'd like to make clearer what I think the problem with your proposal is. X3J11 is not in a position to provide, nor orchestrate the provision of, any part of a C implementation. (This is similar to our reason for not establishing a #pragma clearing house.) At the last meeting, we had a presentation of a useful facility in the same general class as yours, the function of which was to establish inter-translation-unit function parameter type checking (and some other less important services). Even though I believe most Committee members would be all for the promised functionality, we really could not agree to dictate such facilities, for several reasons. For example, there exist C environments on systems like the Apple Macintosh that consist of a closely integrated suite of editing, compilation, debugging, etc. facilities. Such an environment may not have a natural place to insert an "add-on" helper facility, or it may not need one due to providing better facilities. It would be asking a lot for implementors to have to provide such a facility, even if someone made it freely available. Specifying the facility in sufficient detail would be a lot of extra work that would further delay adoption of the Standard. And so on. Some of these objections would also apply to the external name-mapper. Additional problems are brought on by having to maintain a system-wide name pool (which has security ramifications, as well as being a bookkeeping nightmare). For a quality implementation, all the associated system utilities (debuggers, other language compilers, etc.) would have to be modified to understand or at least cooperate with the mapping scheme. I really don't see how you could convince the Committee that the benefits would outweigh the disadvantages. This is not to say that a freely available extern-name-mapper tool would not be a useful contribution to the C programming community -- I think it would be helpful. I strongly suspect that many C projects will simply ignore the 6-character monocase constraint, and they will port readily to a wide range of existing and future systems without requiring any name-mapping tool. You can be sure that every attempt to port an otherwise strictly conforming application to a system with extern name limits is likely to result in complaints aimed at that system vendor. I suspect they'll change their linkers etc. as soon as they've accumulated enough complaints! As to just living with the restriction, I and other well-known C programmers have already pointed out that we've worked within the constraints without major problems for quite some time. There are techniques for avoiding the worst problems brought on by the extern name constraint. The most important one is to limit the number of externs in your application; most C programmers use too many. The next trick is to use "package prefixes"; for example, I recently completed a set of IPC data-exchange modules, where all externally- visible significant names began with "Dx". Other programmers working on other parts of the application are using names with other prefixes, so we don't step on each other's name spaces. Another trick that is sometimes useful is to enclose extern data in a single struct, so that only one name (the struct name) is subject to the extern name constraint. There are other tricks, but I seldom have to resort to them. I agree 100% that it would be "nice" to not have to worry at all about such matters, but then there are lots of more important things that would be "nice" if they were other than what they are..