You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The other intersting thing to talk about is Hash itself. Do you see how we hash in len? That's actually really important! If collections don't hash in lengths, they can accidentally make themselves vulnerable to prefix collisions. For instance, what distinguishes ["he", "llo"] from ["hello"]? If no one is hashing lengths or some other "separator", nothing! Making it too easy for hash collisions to accidentally or maliciously happen can result in serious sadness, so just do it!
Unfortunately, the example is wrong: the two slices given hash to different values, since the length of each str is hashed into the collection. A better example is to use (): since unit contains no data it and slices of them are zero-sized types and all just produce the initial hash value.
IIUC, the linked documentation itself contradicts the text in Filling in Random Bits:
For example, the standard implementation of Hash for &str passes an extra 0xFF byte to the Hasher so that the values ("ab", "c") and ("a", "bc") hash differently.
In the section Filling In Random Bits is written:
Unfortunately, the example is wrong: the two slices given hash to different values, since the length of each
str
is hashed into the collection. A better example is to use()
: since unit contains no data it and slices of them are zero-sized types and all just produce the initial hash value.This repo provides a demonstration of the issue.
I will provide a PR to fix in a moment.
The text was updated successfully, but these errors were encountered: