[m-rev.] for review: rationalise hash functions across the standard library

Peter Wang novalazy at gmail.com
Tue Feb 11 13:03:47 AEDT 2020

On Tue, 11 Feb 2020 12:19:12 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> >
> > Related: should we move towards using hash functions that return uints?
> Ultimately, the hash table implementation requires indexing into an
> array and some of our target languages only support array indexing with
> a signed integer type. (Indeed some of them require the index to be a
> 32-bit type as well, IIRC, so maybe we should move towards hash funtions
> that return an int32?)

Hash functions are more naturally implemented with unsigned ints,
at least in C, where left shifting of signed ints is fraught with
undefined behaviour.

If callers want fewer bits they can truncate it themselves,
which they have to do anyway.

> > should the hash table modules take a hash *function* instead of a
> > predicate?
> I wondered about that too.  Given that Ralph was so keen on using
> fuctions everywhere else it's a bit odd that he decided to use a
> predicate there ...

The original implementation required two hash values.
When I changed it to require only one hash value, I didn't change the
hash predicates to functions.


More information about the reviews mailing list