Fix H3 assumption of an 8-bit byte/char.

The hash function was internally casting the void* data argument into an
unsigned char* and then using values from that to index another internal
array that's dimensioned based on the assumption of 256 values possible
for an unsigned char (8-bit chars/bytes).  This is probably a correct
assumption most of the time, but should be safer to use the limits as
defined in standard headers to get it right for the particular
system/compiler.

There was an unused uint8* casted variable in HashKey::HashBytes that
seemed like it might have been meant to be passed to H3's hash function
as an unfinished attempt to solve the 8-bit byte assumption problem, but
that doesn't seem as good as taking care of that internally in H3 so
users of the API are only concerned with byte sizes as reported by
`sizeof`.  Removing the unused variable addresses #530.

Also a minor tweak to an hmac_md5 call that was casting away const from
one argument (which doesn't match the prototype).
This commit is contained in:
Jon Siwek 2011-08-17 15:03:18 -05:00
parent 82f94881c0
commit d412aa9d63
2 changed files with 12 additions and 8 deletions

View file

@ -168,13 +168,12 @@ hash_t HashKey::HashBytes(const void* bytes, int size)
{
if ( size <= UHASH_KEY_SIZE )
{
const uint8* b = reinterpret_cast<const uint8*>(bytes);
// H3 doesn't check if size is zero
return ( size == 0 ) ? 0 : (*h3)(bytes, size);
}
// Fall back to HMAC/MD5 for longer data (which is usually rare).
hash_t digest[16];
hmac_md5(size, (unsigned char*) bytes, (unsigned char*) digest);
hmac_md5(size, (const unsigned char*) bytes, (unsigned char*) digest);
return digest[0];
}