Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: length of external names Message-ID: <4878@utzoo.UUCP> Date: Mon, 7-Jan-85 17:51:29 EST Article-I.D.: utzoo.4878 Posted: Mon Jan 7 17:51:29 1985 Date-Received: Mon, 7-Jan-85 17:51:29 EST References: <7035@brl-tgr.ARPA> Organization: U of Toronto Zoology Lines: 73 Cc: ihnp4!ucbvax!Schauble@MIT-Multics.ARPA > Henry Spencer, who seems to be one of the chief exponents of short > external names, just posted a convincing explaination of the need to not > break existing linkers. ... To rebut a misconception: I don't like short external names. I merely think that (a) some provision for them in the standard is inevitable, and (b) annoying though this is, we can live with it, which is a passing grade for a standard that has to apply to everyone. > [A] solution that was used, and worked, was to have the COMPILER use the > external "name" to store a hashed value. During the recent net > discussion I posted a description of this technique and some analysis of > the chance and cost of collisions. I don't recall seeing the previous posting about this, but the problem of collisions is definitely a nasty one. Bearing in mind that separately- compiled modules must agree on the object-file (i.e. short) name under which an identifier is known, the possibility of collisions is a major flaw in a hashing scheme. I've worked with compilers that did similar things (first 4 and last 3 chars of the identifier, as I recall) and one had to be careful about collisions; it really wasn't much better than short identifiers. If the algorithm used is really a hashing function rather than a systematic "cut and paste" rearrangement of the original identifier, collisions become (a) less likely, and (b) harder to spot and deal with. Note that hashing *demands* a way to force an internal-to-external correspondence, like the proposed "entry" clause, for linking to system services and other languages. I like the idea of using an "entry" clause to manage correspondences between internal/long and external/short names, although if you ignore the issue of identifiers containing funny characters, you can do exactly the same thing with #define. (Note that preprocessor identifiers are internal, hence must be long.) I am not a member of the committee, but will comment on some of the suggestions addressed to them... > 1. Suppose that the standard required longer names and suggested the > hashing technique as an implementation technique, you would force > manufacturers to update either linker or compiler to meet the > standard. Is this politically possible? I don't know. If the problem of collisions can be shown to be a non-issue, and the "entry" clause or something like it can be introduced, it might be viable. It depends on how manufacturers feel about hashing. > 2. In some other areas, I am told, the standard described a relatively > high level language, rather than the mimimum of implementations. > This will prevent some present compilers from meeting the standard. > Why should it pick the mimimum here? Because the problems go much farther than the compiler. Object-module formats are visible system-wide, making changes much harder. > 3. How can I get a copy of the draft standard? I believe the draft has gone to ANSI for publication for formal public comment; it should be available from CBEMA (don't have the address handy) shortly. The price will be unpleasant, though, knowing CBEMA. I don't know whether the older informal channels are still open. > 4. Is this an adequate method of getting comments and questions to the > committee? If not, what is a useful channel? Some of the committee folks definitely do read this newsgroup. If you want to be forceful about something, though, the recommended course is to write (on a piece of paper) to them. The transition to ANSI formal- public-comment phase may have altered this, though. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry