Re: hash resizing bug

[Jim Meyering]

Eric Blake wrote:
...
> That discards bits, in the case where non-malloced values are being used.  The
> assertion is nice when you know that all values are malloc'd, but is harsh for
> a default.  So, how about I squash this slight modification into my patch
> before pushing this commit?
>
> diff --git i/lib/hash.c w/lib/hash.c
> index 52a211e..c9866c5 100644
> --- i/lib/hash.c
> +++ w/lib/hash.c
> @@ -483,7 +483,14 @@ hash_reset_tuning (Hash_tuning *tuning)
>  static size_t
>  raw_hasher (const void *data, size_t n)
>  {
> -  return (size_t) data % n;
> +  /* When hashing unique pointers, it is often the case that they were
> +     generated by malloc and thus have the property that the low-order
> +     bits are 0.  As this tends to give poorer performance with small
> +     tables, we rotate the pointer value before performing division,
> +     in an attempt to improve hash quality.  */
> +  size_t val = data;
> +  val = (val >> 3) | (val << (CHAR_BIT * sizeof val - 3));
> +  return val % n;

That looks fine.
Though how about adding size_t variants to lib/bitrotate.h?
Then we can use this:

      val = rotr<something> (val, 3);

Hmm... now that I look at the existing definitions in that file,
I'll bet they don't all do a final

            ... & TYPE_MAXIMUM (x)

for nothing.

Then there's the question of the name.
rotr_sz?  rotr_size_t is not kosher since it ends in _t,
which is reserved.  I don't like rotr_sizet.
Maybe rotrsz, but I prefer with the underscore.