Re: [PATCH] ihash ids should be unsigned

[Marcus Brinkmann]

On Sat, Aug 16, 2003 at 09:29:22PM -0400, Roland McGrath wrote:
> > the libihash ids are signed integers, but all users actually provide
> > unsigned integers, and expect it to work.  If a large integer is provided
> > that is cast to a negative number, the hash value will be negative as well,
> > and there will be underflow errors (negative array indices).  I remember
> > that Neal told me he actually saw that happening, but I don't know in what
> > code it was (ours, or code he was hacking) and under which situation. 
> > Anyway, it's apparently wrong.  Neal seems to like to use unsigned long
> > instead, which would give 64 bit on 64 bit arches, but I am more
> > conservative and provide this patch which uses unsigned int.
> 
> Sounds good.  I am sort of inclined to switch to uint32_t or something like
> that.  I don't think there would be a problem using uintptr_t (long) and
> having 64 bits on 64-bit machines.  But it doesn't buy you anything, since
> it's used mostly for PIDs (pid_t = int = 32 bits) and port names
> (mach_port_t = unsigned = 32 bits).

I can do that.  BTW, I have cleaned up libihash from ground up, and used
typedefs for the various types (I just couldn't stand the void ****locps
anymore), put it into the hurd name space (hurd_ihash_foo), and integrated
Neals init/destroy functions for inline struct hash.  I will keep that code
separate for now (in the hurd-l4 tree - will be checked in a couple of
minutes, when I am through), but it could be integrated later if we want to.

I also found a bug in ihash_add, that would do the wrong thing when
the key already existed.  It tries to clean up the old element in this case,
but it won't even find (the loop condition is wrong).  I can fix that,
although I am not sure that any caller depends on that behaviour (I guess
not so).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/