mirror of
https://github.com/zeek/zeek.git
synced 2025-10-02 14:48:21 +00:00
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:
parent
82f94881c0
commit
d412aa9d63
2 changed files with 12 additions and 8 deletions
|
@ -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];
|
||||
}
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue