length of external names

[Mike Schloss]

> 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.