We long ago discussed tracking run length, and reallocating if it exceeded some constant like 16/32. I'd assume this is the "right" fix.
pub struct HashMap<…> { // […] prevent hash collision attacks. hash_state: S, table: RawTable<K, V>, … }
-
-
Also, I wonder if there are any considerations regarding caching seed in thread-local storage w.r.t. fork()/clone().
-
New attack?: 1. Insert N elems 2. Iterate; save iteration order 3. Remove all 2. Re-insert all in same HT in same order
-
Compare to this prior to "fix": 1. Insert N elems into a HT. 2. Force copy of those elems into a new HT. Both O(n**2)?
-
this doesn't work because we don't shrink; the "attack" is reliant on having a lower cap table.
-
so basically you also need to get a shrink_to_fit in there.
-
that's convoluted enough that I think it's reasonable to say "this isn't a significant concern in practice"
-
notably we can suggest the code is wrong because it contains a performance hint that's incorrect.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.