Mail Archives: cygwin/2003/05/10/13:40:25
Christopher Faylor wrote:
>> key = ((st.st_ino & 0xffff) | ((st.st_dev & 0xff) << 16)
>> | ((id & 0xff) << 24));
>>
>>Given the sizes of the various fields of st, there are obvious problems
>>with aliasing here.
>
>
> But, be advised that I'm in the process of changing the inode field to
> a long long so I'm not sure that we wouldn't be just pushing this off
> a little further.
Urk. That's right -- but unless there is another primitive type that is
bigger than 64 bits, then we're out of luck, and will have to accept
aliasing of some sort.
st_dev = 16 bits
st_ino = 64 bits (tentative)
id = 8 bits
To pack that into 64 bits, we need to hash st_ino down from 64 to 40
bits. Given your future implementation of st_inode, what distribution
of values do you expect in the 64bits? This will help to design the
proper hash to minimize conflicts...
Or, we could play some truly evil games, like:
typedef union {
long long value; // only 64 bits long
byte[12] bytes; // 96 bits of storage
} key_t
and then a bunch of accessor macros, and code changes, blah blah. Ugly.
I prefer to hope that the new 64bit inode is sparse, and easily hashed
(fairly unambigiously under expected distribution patterns) down to 40 bits.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -