[OpenAFS] Strange access problems on one client

Marc Dionne marc.dionne@technoconseil.com
Thu, 11 Oct 2007 22:45:08 -0400

Carson Gaspar wrote:
> Hans-Werner Paulsen wrote:
>> On Sun, Oct 07, 2007 at 01:15:00PM -0400, Marc Dionne wrote:
>>> +    else if (hval >= 1<<31)
>> this patch is fine for architectures where the size of "unsigned long"
>> is 4 bytes. But on the x86_64 architecture this will not work, because
>> the size is 8 bytes. One can use "unsigned int".
> Ummm... no. This whole thing is way too fragile. If you care about how 
> many bits the variable has, you MUST use something like uint32_t. Or you 
> can not care, and use sizeof() to generate your comparison. But you MUST 
> NOT use "int" or "long" and hard-code bit shifts.

Sure enough - with the original patch I was trying to confirm that this 
was indeed the issue, and didn't try to be generic.

How about something like this, with an unsigned int for hval:

    else if (hval >= 1<<(sizeof(hval)*8-1))

which seems functionally equivalent to the original code and not 
dependent on the size of hval.

Now I'm curious as to why the specific value returned by DirHash even 
matters.  Even with the gcc bug it would be consistent for a given 
string on the same client.  Does this value have to match what's 
computed for the same string on the file server side? (looks like 
DirHash is also used in fileserver) If so, it looks like the original 
code could produce different values with different size ints on the 
server and client.