Re: [boost] [interprocess] boost::hash - different values forthesame input?

Subject: Re: [boost] [interprocess] boost::hash - different values forthesame input?
From: Peter Dimov (lists_at_[hidden])
Date: 2016-01-14 17:52:42

Daniel James wrote:
> On 14 January 2016 at 04:54, Peter Dimov <lists_at_[hidden]> wrote:
> > Daniel James wrote:
> >
> >> The reason why I originally wrote that note was because it can generate 
> >> different hash values when compiled for different platforms or 
> >> architectures, e.g. a 32-bit executable might generate a different hash 
> >> value to a 64-bit executable.
> >
> > Is this just because of pointers and floats, or are there other reasons? 
> > size_t hashing to different values perhaps?
>
> Anything with a bigger range than size_t will have to, e.g. int64_t will 
> hash differently on 32 and 64 bit machines.

Yes, my question was a bit stupid because the return value of hash<> is 
size_t. A better way to put it would be whether the lower 32 bits of the 
return value need to differ on 32 and 64 bit platforms.

I realize that there's a way to hash uint64_t to different values, but there 
are also ways to make it hash to the same value (mod 2^32).

Apart from that, people have argued recently that hash values should vary 
for each process run. That's because of security considerations with hash 
tables - an attacker can supply input that is known to create collisions and 
can so degrade the hash table's performance and effect a denial of service.

When this came up on the std reflectors, I argued that the proper way to 
tackle this issue was not to make the standard hash function 
nondeterministic, but to have the containers use a random seed when hashing 
an element.