Spec request. Hasher: is write_u32 eqivalent to 4 calls of write_u8?

[stepancheg]

Currently Hasher::write_u32 is implemented as self.write(&unsafe { mem::transmute::<_, [u8; 4]>(i) }). The question is: is it a requirement for all Hasher implementations?

In other words, is is true, that for each hasher implementation, call

hasher.write_32(0x01020304);

must be equivalent to

hasher.write_8(0x04);
hasher.write_8(0x03);
hasher.write_8(0x02);
hasher.write_8(0x01);

?

(assuming host is little-endian).

Why is it important.

Suppose, you want to implement very simple hasher with state updated like state = state * 31 + update.

If Hasher does not have requirement as above, hasher can be implemented by simply casting any operand to u64 and avoiding dealing with unaligned/smaller than u64 integers:

impl Hasher for MyHasher {
    fn write_u8(&mut self, v: u8) {
        self.write_u64(v as u64);
    }

    fn write_u64(&mut self, v: u64) {
        self.state = (self.state * 31).wrapping_add(v);
    }
}

[nagisa]

I’m fairly sure there was a discussion about it before and we decided against doing any changes to the libstd impl. Don’t exactly remember the reason, though.

[stepancheg]

If any decision is made, I wish it would be stated in the documentation of Hasher trait.

[qnighy]

StableHasher in the compiler employs a different implementation to achieve platform-independence.

[michaelwoerister]

I don't think there's any such requirement. The FxHasher in the compiler does exactly what your example does.

[alercah]

I think I would be opposed to this requirement; it imposes a performance penalty for systems of the "wrong" endianness, since they would need to correct their endianness. The only requirement on Hasher should be that the same sequence of write* calls produces the same result, I think.

[clarfonthey]

My spec request: given two byte slices first and second, is hasher.write(first); hasher.write(second); equivalent to hasher.write(first + second) ?

This way, we could define all the non-slice methods as explicitly being transmutes, always.

[steveklabnik]

removing T-doc until @rust-lang/libs lets us know what to document here.

[Amanieu]

My personal take on this is that we should only guarantee that Hasher produces the same value for the exact same sequence of write* calls. This even applies to plain write calls on byte slices: a Hasher is only guaranteed to produce the same result if the same sequence of write calls are used with the same slice lengths.

For an example of where this could make a difference, consider this code from Abseil which hashes short slices by reading 0-16 bytes and padding anything not included in the length with zeroes or duplicates of the existing bytes.

[Amanieu]

Based on the libs team decision in #80303 (comment), I'm going to close this issue. The answer to the question in the issue title is no: write_u32 is not required to be equivalent to 4 calls of write_u8.

[alercah]

Was there any updates to the documentation of Hasher? I didn't see any in a quick scan of threads.

[clarfonthey]

Yeah, it seems like the thread was closed because the original idea was decided to not be done, but I agree that it shouldn't be closed until documentation is added.

[clarfonthey]

cc @Amanieu who closed this since it shouldn't be closed. Opened #83390 to add docs for this, but think this issue should be kept open until we've finally decided on how to document this.