Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-12-05 08:16:20

On 4 Dec 2014 at 10:35, Howard Hinnant wrote:

> > I think this sufficiently important to warrant a separate N-paper 
> > proposing a std::secure_hash<T> based on SipHash. Howard, you up for 
> > that?
> 
> Thanks, but no, I don´t think I can do that.
> 
> SipHash isn´t the ultimate answer in hash security.  It is the front
> line in a never ending war.  SipHash arrived on the scene two years ago.
>  I didn´t learn of it until a year ago.  Many people are just learning
> of it now.  We can´t possibly standardize it for another 3 years. 
> 
> The standardization process is way too slow for this kind of thing.  In
> order to be effective, the standard needs to enable the programmer to
> choose the latest available weaponry.  Because by the time we
> standardize algorithm X as the algorithm of choice in
> std::secure_hash<T>, odds are going to be good that it has already been
> attacked, and made obsolete by a better algorithm. 
> 
> The most I could back is offering SipHash as one of the customizable
> HashAlgorithms that could be used in hash_append.  
> 
> This is worlds different than std::secure_hash<T>, because when you
> author hash support for MyClass, std::secure_hash<MyClass> locks you in
> to a std-supplied algorithm, be it SipHash, or something else.  That is
> bad.  But when you instead write your hash support in terms of a
> hash_append which is templated on HashAlgorithm, then you can use
> SipHash, or any other hashing algorithm, without ever having to revisit
> MyClassTMs hash support code again. 
> 
> Subsequently this means that when your unordered_set<MyClass> is
> attacked, you can do something about it (overnight!) without waiting
> years for a committee to come to your rescue. 

You seem to be assuming that a std::secure_hash would be implemented 
inline. It need not be so, it could be implemented via an extern 
implementation in a shared library, and therefore an OS security 
update could push replacements.

I'd assume that wouldn't fly as code depending on the ordering of an 
unordered map would break, so the committee would say no. So that 
brings us back to your alternative.

Howard are there good reasons why your reference library for N3980 
hasn't been submitted to Boost for review and inclusion? With 
something like my forthcoming BindLib a single code base can be dual 
use, so both compilable as a Boost module and as a totally 
independent standalone library.

I'd also think that N3645 would swing more weight if already 
implemented and used within Boost. Long road to implementing that 
though. And we could do with better map STL container design anyway.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/