Rollup merge of #90995 - the8472:hash-portability, r=dtolnay
Document non-guarantees for Hash Dependence on endianness and type sizes was reported for enum discriminants in #74215 but it is a more general issue since for example the default implementation of `Hasher::write_usize` uses native endianness. Additionally the implementations of library types are occasionally changed as their internal fields change or hashing gets optimized. ## Question Should this go on the module level documentation instead since it also concerns `Hasher` to some extent and not just `Hash`? resolves #74215
This commit is contained in:
commit
43279b2749
@ -164,6 +164,19 @@ mod sip;
|
||||
/// `0xFF` byte to the `Hasher` so that the values `("ab", "c")` and `("a",
|
||||
/// "bc")` hash differently.
|
||||
///
|
||||
/// ## Portability
|
||||
///
|
||||
/// Due to differences in endianness and type sizes, data fed by `Hash` to a `Hasher`
|
||||
/// should not be considered portable across platforms. Additionally the data passed by most
|
||||
/// standard library types should not be considered stable between compiler versions.
|
||||
///
|
||||
/// This means tests shouldn't probe hard-coded hash values or data fed to a `Hasher` and
|
||||
/// instead should check consistency with `Eq`.
|
||||
///
|
||||
/// Serialization formats intended to be portable between platforms or compiler versions should
|
||||
/// either avoid encoding hashes or only rely on `Hash` and `Hasher` implementations that
|
||||
/// provide additional guarantees.
|
||||
///
|
||||
/// [`HashMap`]: ../../std/collections/struct.HashMap.html
|
||||
/// [`HashSet`]: ../../std/collections/struct.HashSet.html
|
||||
/// [`hash`]: Hash::hash
|
||||
|
Loading…
x
Reference in New Issue
Block a user