std::hash::Hasher (code) is not currently portable: it doesn’t fix the Endianness of input. This is fine for
HashMap but useless for anything needing portable output (cryptographic hashes, checksums, file systems, etc. (in my case: a reproducible mechanism for seeding PRNGs from arbitrary input)).
Making it portable (with some fixed “personality” i.e. arbitrary Endianness) would only require adding
.to_be() on the input (although of course the implementation is still responsible for making sure
finish() returns a portable result). I don’t think this would be considered a breaking change because the results are not currently portable and this is currently only useful consistent results are not required anyway (excepting possibly platform specific stuff).
Would there be much performance impact?
.to_le() is a no-op on x86 anyway. ARM is normally also LE. There are some BE architectures; I have little idea what overhead an extra byte-swap would have in practice.
Limitation: portable hash functions must specify expected Endianness of input. So choosing an arbitrary Endianness here would not make the trait compatible with all hash functions.
Motivation: make the
Hasher trait more widely useful.
Note: the output type is still limited to
u64. This isn’t necessarily a problem though since alternative output functions can be added, as part of the trait or not. The following would be a very flexible option:
/// Size of state in bytes (i.e. optimal output size) fn state_size(&self) -> u32; /// Fill the output buffer from the state. If the output is longer /// than the state, then the hash function should be used to mutate /// the state as many times as necessary to generate the required /// length of data, as with a random number generator. fn fill_output(&mut self, buf: &mut [u8]);