makekeys [was: Re: Current tinderbox regression (libX11)]

[James Cloos]

So, the issue is that best_z is initialized to 0 but only updated if:

    max_rehash < MIN_REHASH && max_rehash < best_max_rehash

If that does not happen before z hist KTNUM the loop falls through and z
gets set to 0 in the line 'z = best_z;'.

One possiblity would be to just error out after next1: if best_z is
still 0 with a message that KTNUM needs to be increased.

Or, not constrain z to be less than KTNUM and use something like:

    z < KTNUM : z ? KTNUM-1

where it gets used as an array index.  That would include setting the
initial value of i in the loop which NULLs the end of the name array
and the j in tab[j].

Or a complete rewrite of the optimal hash algorithm. :)

OTOH, it may be the case that KTNUM can safely be made large enough to
guarentee a solution.  WIth 32 bit ints and 32 bit struct memeber
alignment the KTNUM-dependent arrays in makekeys need 136*KTNUM octets
of VM.  So the current setting uses about half a meg of VM.  With 64bit
pointers that is just under one meg.  Even doubling KTNUM would only be
a hardship for those compiling on (not just for) archaic or embedded
boxen.

I'm leaning towards an informative error message and future increments
of KTNUM as needed to find a happy hash value.

Comments?

Incidently, with the current keysyms it would have been sufficient to
increase KTNUM to 3200 since it tests up to 3193 and then chooses 3079
as the best option.  But I left it at $(primes 4096|tail -1) (having
chosen a prime for no good reason :) to future proof it.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6