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!adm!vis!greg@bass.nosc.MIL From: greg@bass.nosc.MIL Newsgroups: comp.lang.c Subject: Re: MAJOR ANSI C FLAW (my opinion, of course) Message-ID: <10065@brl-adm.ARPA> Date: Fri, 30-Oct-87 01:15:21 EST Article-I.D.: brl-adm.10065 Posted: Fri Oct 30 01:15:21 1987 Date-Received: Wed, 4-Nov-87 05:44:51 EST Sender: news@brl-adm.ARPA Lines: 88 Thanks to Doug and others for responding to my proposal, I'm grateful for the attention its getting. Let me take a few minutes and respond to some of the points which Doug raised. From: Doug Gwyn Subject: Re: MAJOR ANSI C FLAW (my opinion, of course) Date: 26 Oct 87 21:05:11 GMT To: info-c@BRL-SMOKE.arpa It's not clear what good it would do to send this to X3J11. My understanding is that X3J11's restriction on external names will cause the writers and standardizers of C bindings for libraries and packages to use much less mnemonic names than they would wish. Given all of the fancy graphics, database, window managing, mathematics, etc. libraries and packages we're accumulating, this restriction will significantly reduce the clarity of our code, leading to many errors during development, and much more trouble and expense during program maintenance. On top of that, all of these little unmnemonic names, and the comments and defines which try to explain them will be ugly. My impression is that X3J11 appreciates this and has only agreed to the restriction because no other way was seen to allow C to work with standard linkers - a necessity, I agree. My proposal provides a way to have long identifiers AND work with existing linkers. It is intended to allow X3J11 to give external identifiers the same requirements as for internal ids, without compromising portability or X3J11's mandate. As Doug and other members of X3J11 has said, this is what they want but thought they couldn't have. Since information is being lost, in general you can also get collisions between short version of names across multiple translation units (object modules), since they're compiled entirely separately so that no single hash table can guarantee uniqueness (unless you want to maintain a system-wide single hash table for all C external identifiers ever seen). This is a good point. It is indeed necessary for a renaming tool to keep a table of all external identifiers in a program undergoing renaming. In the design sketch I presented, an identifier table with the renamings assigned so far would be constructed from a renamings file before processing each module, and the renamings file would be updated afterwards. The renamings files would have a simple structure so that they could easily be produced for non-C modules, even by hand. To have consistent renamings across a set of programs, just reuse the same renamings file. If the short names do not bear notable resemblance to the original longer names, it makes debugging even harder than it already is. Quite so. For this reason, I proposed simply adding a short distinctive prefix to names which collide. This leaves the original spelling intact following the prefix. If the prefix syntax is reserved, the renamings can be reversed merely by stripping off any such prefixed identifiers (identifiers which accidentally already had the prefix would simply get an extra one when renamed). I think it's easier to address this problem before coding than to try to solve it after the fact. This point is very hard to take seriously. In addition to the mountains of exiting code, who knows what libraries and packages new programs will wind up being linked with during future maintenance? Practically all questions being debated by X3J11 would be moot if programmers could somehow do all the right things when writing code. But remember, the biggest problem I see with X3J11's allowing reduced external name significance is what it will do to writers of libraries and packages. With a renaming tool available, such code can use natural and mmemonic identifiers. When a library or package is installed in a deficient environment, the renaming program will be run, and all programs which use that library or package will use the (same set of) renamings which were produced. 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. _Greg J. Greg Davidson Virtual Infinity Systems +1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA greg@vis.uucp ucbvax--| telesoft--| greg%vis.uucp@nosc.mil decvax--+--sdcsvax--+--vis greg%vis.uucp@sdcsvax.ucsd.edu ihnp4--| nosc--|