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.