Bug 180363 – WTF Hasher: disallow -0. and NaNs

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Web Template Framework

[JF Bastien]

I want to see if we can just outright disallow them by adding a debug check that we never hash them. This is based on a discussion here:
  https://bugs.webkit.org/show_bug.cgi?id=180318

Let's see what the tests say, and if anyone has opinions.


Original comment:

I've been thinking about this, and I think there are 3 things we could plausibly want:

  1. Deal with bits only, treating -0. != +0. and all NaNs with different payload as different (and same payload as the same).
  2. Deal with IEEE-754 semantics, treating -0. == +0., and all NaNs as different.
  3. Ban -0. and all NaNs from hashing.

I think these all make sense in different context, but choosing 1. and 2. requires knowing what situation we're in! It seems like 3. is the most conservative thing to do if we don't know how hashing is used.

[JF Bastien]

Created attachment 328355 [details]
patch

[JF Bastien]

Created attachment 328362 [details]
patch

Fix typo.

[JF Bastien]

Created attachment 328377 [details]
patch

Missing include.

[EWS Watchlist]

Attachment 328377 [details] did not pass style-queue:


ERROR: Source/WTF/wtf/Hasher.h:26:  Alphabetical sorting problem.  [build/include_order] [4]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[JF Bastien]

Created attachment 328406 [details]
patch

Comment out long-running test.

FWIW I also test that all 16-bit values hash uniquely (they do) and that the collision rate is low for 32-bit values (it's 3%). I haven't checked the clustering of collisions in 32-bit. Presumably if we wanted to prevent hashflood we'd use another hash and we would mix in a per-process salt anyways.

[JF Bastien]

Not sure we want to do this. Closing.