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

Subject: Re: [boost] [interprocess] boost::hash - different values for the same input?
From: Daniel James (dnljms_at_[hidden])
Date: 2016-01-13 17:07:02

I altered the subject to include interprocess, since this is relevant there.

On 9 December 2015 at 20:13, trafdev <trafdev_at_[hidden]> wrote:
>
> As per hash_range docs
> (http://www.boost.org/doc/libs/1_59_0/doc/html/hash/reference.html#boost.hash_range_idp93681104):
>
> "This hash function is not intended for general use, and isn't guaranteed to
> be equal during separate runs of a program - so please don't use it for any
> persistent storage or communication."
>
> As per code
> (http://www.boost.org/doc/libs/1_59_0/boost/functional/hash/hash.hpp) it
> uses hash_combine_impl which doesn't use any random, process_id etc values
> which might change during new process launches.
>
> At the same time, in an example describing container usage in the shared
> memory
> (http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/allocators_containers.html#interprocess.allocators_containers.additional_containers),
> boost::hash is being used:
>
> typedef boost::unordered_map
>       < KeyType               , MappedType
>       , boost::hash<KeyType>  ,std::equal_to<KeyType>
>       , ShmemAllocator>
>    MyHashMap;
>
> 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.