Fix FNV bug on 64-bit Windows (hashes being cut off to 32-bit) #211
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Merged in #213 |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
Feb 11, 2022
Version 1.4.0.2 * Restore older GHC support * Support GHC-9.0.2 Version 1.4.0.1 * text-2.0 compatibility Version 1.4.0.0 * Eq is now a superclass of Hashable. Also Eq1 is a superclass of Hashable1 and Eq2 is a superclass of Hashable2 when exists. * Remove Hashable1 Fixed instance * Remove Hashable1 Semi.Min/Max/... instances as they don't have Eq1 instance. Version 1.3.5.0 * Add Solo instance (base-4.15+, GHC-9+) Version 1.3.4.1 * Fix compilation on 32 bit platforms * Fix Tree instance Version 1.3.4.0 * Text and ByteString hashes include length. This fixes a variant of haskell-unordered-containers/hashable#74 for texts and bytestrings. haskell-unordered-containers/hashable#223 * Use correct prime in combine. This should improve the hash quality of compound structures on 64bit systems. haskell-unordered-containers/hashable#224 * Add instance for types in containers package haskell-unordered-containers/hashable#226 * Change Int, Int64 and Word64 hashWithSalt slightly. haskell-unordered-containers/hashable#227 Version 1.3.3.0 * Text hashing uses 64-bit FNV prime * Don't truncate Text hashvalues on 64bit Windows: haskell-unordered-containers/hashable#211 Version 1.3.2.0 * Add Hashable (Fixed a) for base <4.7 versions. * Add documentation: * hashable is not a stable hash * hashWithSalt may return negative values * there is time-compat with Hashable instances for time types. * Add random-initial-seed flag causing the initial seed to be randomized on each start of an executable using hashable.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I observed an issue in my app where many input values (of a nested record type) were being hashed to the same value, and eventually determined it was only happening on Windows. After tracing the problem back, I noticed
Textvalues were always being hashed to 32-bit values, and that when I combined the hashes of(record, text), the input record hash (used as salt) was also being cut off to 32-bit.That led me to these issues with
fnv.c. It is usinglongwhich is 32 bits on 64-bit Windows. However HaskellInt, as well asWORD_SIZE_IN_BITS, are 64. So hashes in general are 64-bit, but then getting improperly cut off when they interact with this code, such as throughTextand other byte array types. I also noticed theFNV_PRIMEconstant added recently was not actually being used; I assume it was supposed to replace the numeric constant in the function below.I tested that this fixes the hash behavior in my app, but I have not tested on a 32-bit platform yet.