4 ms·

Javascript is kinda weird as the numerical keys have their own special ordering. Python is probably the better known one, as it went through "arbitrary but det

Javascript is kinda weird as the numerical keys have their own special ordering. Python is probably the better known one, as it went through "arbitrary but deterministic" (before 3.3) to "wilfully non-deterministic" (from 3.3 to 3.6) to "insertion ordered" from 3.6, the latter of which was initially an implementation detail of improving the hashmap but was then made into the language spec starting 3.7.

Yoric 2y ago
I remember that it actually broke a critical algorithm I was testing at the time. Fun times.
zbentley 2y ago
Perl also changed its behavior, but in the other direction: a random seed was used per interpreter start after 5.18. https://www.perlmonks.org/?node_id=1005122 https://www.perlmonks.org/?node_id=1005122
- masklinn 2y ago
  That's actually the first python transition I mentioned, per-process hash randomisation had the effect of making map iteration non-deterministic. I believe in both cases this was in response to the hashdos concern / attacks.
  - zbentley 2y ago
    Ah, sorry I didn't read that closely. One minor nit (which the Perl press releases also mess up): the randomisation is per-interpreter, not per-process. That's not a pedantic distinction. I've seen a couple of bugs/bad behaviors caused by forking servers forgetting to call srand(3)/re-randomize the hash seed after fork(2) and then relying on more randomness than they actually have. Suddenly (for example) hashing rate limiters or bloom filters all operate in near-lockstep, which can cause significant issues at high volumes. Forking has also caused randomness-related issues (though not necessarily specifically re: hashing) for Rust[1] and Ruby[2], and probably many other platforms. OpenSSL seems to sidestep[3] the issue by using the PID as part of its salt internally. 1: https://github.com/rust-lang/rust/issues/16799 https://github.com/rust-lang/rust/issues/16799 2: https://bugs.ruby-lang.org/issues/4579 https://bugs.ruby-lang.org/issues/4579 3: https://wiki.openssl.org/index.php/Random_fork-safety https://wiki.openssl.org/index.php/Random_fork-safety

Yoric 2y ago

I remember that it actually broke a critical algorithm I was testing at the time. Fun times.

zbentley 2y ago

Perl also changed its behavior, but in the other direction: a random seed was used per interpreter start after 5.18. https://www.perlmonks.org/?node_id=1005122 https://www.perlmonks.org/?node_id=1005122

masklinn 2y ago
That's actually the first python transition I mentioned, per-process hash randomisation had the effect of making map iteration non-deterministic. I believe in both cases this was in response to the hashdos concern / attacks.
- zbentley 2y ago
  Ah, sorry I didn't read that closely. One minor nit (which the Perl press releases also mess up): the randomisation is per-interpreter, not per-process. That's not a pedantic distinction. I've seen a couple of bugs/bad behaviors caused by forking servers forgetting to call srand(3)/re-randomize the hash seed after fork(2) and then relying on more randomness than they actually have. Suddenly (for example) hashing rate limiters or bloom filters all operate in near-lockstep, which can cause significant issues at high volumes. Forking has also caused randomness-related issues (though not necessarily specifically re: hashing) for Rust[1] and Ruby[2], and probably many other platforms. OpenSSL seems to sidestep[3] the issue by using the PID as part of its salt internally. 1: https://github.com/rust-lang/rust/issues/16799 https://github.com/rust-lang/rust/issues/16799 2: https://bugs.ruby-lang.org/issues/4579 https://bugs.ruby-lang.org/issues/4579 3: https://wiki.openssl.org/index.php/Random_fork-safety https://wiki.openssl.org/index.php/Random_fork-safety