Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site dataio.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!vax135!cornell!uw-beaver!uw-june!entropy!dataio!bright From: bright@dataio.UUCP (Walter Bright) Newsgroups: net.lang.c Subject: Re: length of external names Message-ID: <537@dataio.UUCP> Date: Wed, 9-Jan-85 12:29:39 EST Article-I.D.: dataio.537 Posted: Wed Jan 9 12:29:39 1985 Date-Received: Fri, 11-Jan-85 22:52:40 EST References: <7035@brl-tgr.ARPA> Organization: Data I/O Corp., Redmond WA Lines: 25 > The 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. > > This is done entirely in the compiler, and has no effect on the linker. > > To the net at large: > > 1. What are specific objections to the hashing technique? a) Reading linker maps would be terrible. b) All the other tools that depend on the global symbol table would be messed up. So, you say, rewrite the tools so they inverse hash the symbols. So then it would be easier to just fix the linker, and we're back where we started. My solution to the external symbol dilemma is that it should be implementation-defined, since the behavior is determined by the linker and the compiler writer typically has no control over the linker. If code is being ported to a machine with a smaller linker, the programmer could 'hash' the overly long externals himself with macros.