Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-12-02 15:44:10
On 2 Dec 2014 at 20:27, Stephan T. Lavavej wrote:
> [Niall Douglas]
> > BTW I think MSVC/Dinkumware *has* fixed their std::hash<>, theirs is
> > several orders of magntitude more complex than the trivial hash
> > libstdc++ uses. Indeed this leads to MSVC's apparent poor
> > unordered_map performance when compared to GCC (about a 12-40%
> > performance loss).
> > Stephan can probably confirm or refute this claim of MSVC/Dinkumware
> > having a safe hash though. It may just be he uses a well distributed
> > hash instead of a trivial hash, not one cryptographically safe.
> VC currently uses FNV-1a for everything. This is good at jumbling up
> bits, and pretty fast (although not as fast as returning an integer
> unchanged), but it is absolutely not cryptographically secure, nor does
> it attempt to resist collisions triggered by an intelligent adversary.
> We reserve the right to change our hash implementation in the future.
Thanks for the confirm Stephan.
Out of curiosity I went and looked up what Python did to solve this
(here's the discussion: http://bugs.python.org/issue13703). In the
end, they simply XOR salted the hash with a cryptographically
generated random number produced at process launch (source:
and carried on with their previous algorithm.
I think std::hash could be similarly adjusted with ease, the hard
part is generating a cryptographically secure random number. I don't
believe C++ 11 even has such a secure generator in <random> even ...
nevertheless, the C++1z standard might consider adding a static
function to the STL which sets the std::hash salt value to something.
It might be an idea to only permit that function to be called exactly
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/