summaryrefslogtreecommitdiff
path: root/signal_renames.txt
diff options
context:
space:
mode:
authorHein-Pieter van Braam <hp@tmm.cx>2017-04-14 11:28:51 +0200
committerHein-Pieter van Braam <hp@tmm.cx>2017-04-14 11:31:18 +0200
commit8ff6e538336135837630e313027826e9bd8d036e (patch)
tree04349ee90351e83adec5874c55e69f0ba271b9a7 /signal_renames.txt
parentc4d3dd1a486479b243999bdc30bf26e5683a3b33 (diff)
Correct Variant::hash_compare()
There was a logic error in #7815 which made Variant.hash_compare() == Variant.hash_compare() always true. In an attempt to short-circuit the NaN check I made an (in hindsight) obvious error: 10 == 12 || is_nan(10) == is_nan(12) This will be true for all inputs, except for the NaN, not-NaN case. The macro has been updated to now generate: (10 == 12) || (is_nan(10) && is_nan(10)) so: (10 == 12) || (is_nan(10) && is_nan(12)) = false False or (False and False) is False (10 == 10) || (is_nan(10) && is_nan(10)) = true True or (False and False) is True (Nan == 10) || (is_nan(NaN) && is_nan(10)) = false False or (True and False) is False (Nan == Nan) || (is_nan(NaN) && is_nan(NaN)) = true False or (True and True) is True Which is correct for all cases. This bug was triggered because the hash function for floating point numbers can very easily generate collisions for the tested Vector3(). I've also added an extra hashing step to the float hash function to make this less likely to occur. This fixes #8081 and probably many more random weirdness.
Diffstat (limited to 'signal_renames.txt')
0 files changed, 0 insertions, 0 deletions