bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hash resizing bug


From: Jim Meyering
Subject: Re: hash resizing bug
Date: Thu, 18 Jun 2009 21:09:06 +0200

Eric Blake wrote:

> According to Jim Meyering on 6/18/2009 11:37 AM:
>>> +  size_t val = data;
>>> +  val = (val >> 3) | (val << (CHAR_BIT * sizeof val - 3));
>>> +  return val % n;
>>
>> That looks fine.
>
> Added as:
>
> size_t val = (size_t) data;
> val = ((val >> 3) | (val << (CHAR_BIT * sizeof val - 3))) & SIZE_MAX;
>
> to address concerns about casting (I didn't get any warning with the
> implicit cast, but understand that void*->size_t is different than
> void*->intptr_t, so the cast makes it obvious), and to address the
> possibility that size_t might be less than int (is there such a platform?).
>
>> Though how about adding size_t variants to lib/bitrotate.h?
>> Then we can use this:
>>
>>       val = rotr<something> (val, 3);
>
> For rotr64, it is probably superfluous; but for sizes smaller than int
> smaller sizes it makes a difference.  I think that warrants a separate
> patch, since it also changes the dependencies for hash.c, as well as
> touching the bitrotate module.  But it does sound like a nice idea.

Committing it as a separate patch makes sense.
In the mean time, you might as well define rotr_sz right in hash.c.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]