Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/3/84; site enmasse.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!teddy!panda!enmasse!mike From: mike@enmasse.UUCP (Mike Schloss) Newsgroups: net.lang.c Subject: Re: Re: length of external names Message-ID: <275@enmasse.UUCP> Date: Thu, 10-Jan-85 18:56:20 EST Article-I.D.: enmasse.275 Posted: Thu Jan 10 18:56:20 1985 Date-Received: Sat, 12-Jan-85 06:20:36 EST References: <7129@brl-tgr.ARPA> Organization: Enmasse Computer Corp., Acton, Mass. Lines: 24 > One other comment on the hashing technique: When I made the original > posting I assumed the linker model I was most familiar with: one > external definition and a series of references. For this model, having > two C symbols that hash to the same external is not very much of a > problem. The linker will see two different definitions of its symbol > and should complain. This will work fine for one object module and one or more libraries, but what about multiple object modules??? Like when you compile a kernel, shell, or other large (multi source file) utility. > The numbers given also assumed the shortest linker name space I was > aware of, 30 bits. For anything larger (GCOS, 36 bits, MS-DOS, 64 > bits), the probability of collision is too small to compute on the > equipment I have at hand. The probability is too small... Does this mean it will never occur. Would you like to find the bug that an unreported collision will cause if (when) it does happen. Or, would this be the first place you would look if you did have a elusive bug. P.S. Assuming hashing is used... A possible solution to finding this rare bug would be to recompile everything (libraries and all) using an alternate hashing function.