Re: [boost] [interprocess] boost::hash - different values for the same input?

Subject: Re: [boost] [interprocess] boost::hash - different values for the same input?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-01-13 17:18:03

On 2016-01-14 01:07, Daniel James wrote:
> I altered the subject to include interprocess, since this is relevant there.
>
> On 9 December 2015 at 20:13, trafdev <trafdev_at_[hidden]> wrote:
>>
>> My question is: is it safe to use boost::hash in a shared (persistent)
>> storage or it's safe only for a particular (non-pointer) types?
>>
>> In this case, boost::hash docs should be changed to mention this exceptions,
>> because otherwise no one could use boost::hash in a shared memory
>> containers.
>
> Sorry about the very slow reply. I'm afraid the answer is that it
> depends. 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. Also, I occasionally
> change the algorithm in new versions of boost (and probably will in
> the next version). For interprocess this currently won't be an issue
> if all the processes are using the same executable, or using
> executables built with same version of boost and the same
> architecture, but could be a problem if that isn't the case. So maybe
> the Interprocess documentation needs to explain this.
>
> But there's another problem coming up. The last proposal I saw for a
> standard generic hash function will support randomized hash functions
> (such as siphash) which will only work with interprocess if they are
> somehow seeded identically. I'll want to support whatever is accepted
> to the standard (although maybe as a separate library). I'll need to
> catch up with how that is progressing, as I haven't kept up to date.

Do you think we could add a few well-known hash functions to Boost.Hash 
so that they could be used for consistent results?