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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-12-02 18:17:55

On 2/12/2014 07:45, Gottlob Frege wrote:
> On Sun, Nov 30, 2014 at 6:20 PM, Gavin Lambert <gavinl_at_[hidden]> wrote:
>> On 29/11/2014 08:01, Gottlob Frege wrote:
>>> There are still reasons to use std::map over unordered_map.  Lack of a
>>> cryptographically safe hash is one of them.  There are others (that
>>> I've forgotten, but I've asked the same question to committee members
>>> before, and there were a few reasons that sounded valid to me.)
>>
>> Why should the lack of a cryptographically safe hash matter when you are not
>> doing cryptography?
>>
>> It doesn't really matter what hash is used in internal data structures.
>> (Although obviously there are desirable properties such as having uniform
>> spread to minimise bucket collisions and improve lookup speed.)
>
> Denial of Service attack - I carefully force the input data such that
> the hashes collide and you get worse-case hash-table performance.
> This is a real attack.  Python and a few other languages have already
> fixed their hashes, we have not.
>
> So that still doesn't apply to every app, but it applies to more than
> you might expect.

Perhaps I'm just being naive, but I would think that there'd be more 
non-internet-facing apps than internet-facing ones (or at least the 
probability of any given application facing attack is fairly slim, apart 
from the really popularly installed ones), so most applications would 
prefer high-performance defaults over "secure" ones.

Though I fully agree that it'd be nice to have a secure hash as an 
option, I don't see why eg. std::hash<size_t> (or any smaller type) 
doesn't just return the bitwise equivalent of the original value by 
default, as this has zero collision probability and the highest performance.