Re: [hash2] Review

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-12-13 21:00:37

Le vendredi 13 décembre 2024 à 19:24 +0200, Peter Dimov via Boost a
écrit :
> Julien Blanc wrote:
> ...
> > * remove default construction and too short key construction for
> > algorithms where this is actually harmful (such as siphash). I
> > don't have an issue with providing constructors with keys for
> > algorithms that do not mandate it.
> > Â  But boost code should encourage correct usage of the algorithms
> > it propose,
> > Â  not allow bad usage in the name of genericity.
> ...
> > * makes copy construction requirement on hash algorithm a
> > requirement only
> > Â  if hash_append_unordered_range is used. Hashing unordeder ranges
> > is an
> > Â  open problem, some creative other solutions may be found, and i
> > see no
> > Â  reasons why they would involve duplicating the algorithm state.
> > Actually,
> > Â  if the hash is default constructible, then it is not needed. You
> > need
> > Â  either one of default or copy constructible, not both.
> 
> I already answered this (twice) - using default constructed hash
> algorithm instances in hash_append_unordered_range makes collisions
> seed-independent.

And it seems we won't agree here. IMHO it's not worth it. The potential
for misuse and its consequences far outweight the ease of
implementation that it provides.

> But this aside, these two points also contradict each other. The
> first one wants to remove default construction from SipHash; the
> second one wants to use default construction in
> hash_append_unordered_range. If both are applied,
> SipHash will not work in hash_append_unordered_range.

Obviously i failed at explaining my point, because i see no
contradiction. My point is that for unordered range hashing, you can
keep your scheme and need either:

1. use a default constructed hash
2. use a copy constructed hash from the given hash. This makes the hash
  less predictable.

But not both. The current implementation uses #2, but it could use #1
if #2 is not provided and #1 is available (typical use case for #1
would be openssl md5, whereas typical for #2 is siphash in
boost::hash2).

If you have neither #1 or #2, then you cannot hash unordered
containers. But you can hash everything else. And it will be fine for a
lot of users.

Hope i made myself a little clearer,

Regards,

Julien
>