Bug #4818
open
murmurHash3 of uint32_t is not endian safe
0%
Description
murmurHash3 of an uint32_t value computes the hash of the in-memory 4-byte buffer. If this is part of a data structure that is sent to another computer with a difference between big endian and little endian, then they won't compute the same hash.
https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/util.cpp#L103
Maybe this should use endian::native_to_little, similar to the TLV encoder (Intel chips use little endian):
https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/encoding/encoder.cpp#L151
Updated by Anonymous about 5 years ago
... although it looks like the implementation of murmurHash3 itself will compute a different result on big and little endian machines.
https://github.com/named-data/PSync/blob/0cf4b600e91455ee07c38eb22876aa6b653bc14b/PSync/detail/util.cpp#L47
Updated by Ashlesh Gawande about 5 years ago
- Related to Task #4659: Look into using newer and better hash function added
Updated by Davide Pesavento about 4 years ago
Jeff Thompson wrote:
... although it looks like the implementation of murmurHash3 itself will compute a different result on big and little endian machines.
I can confirm this. For instance, the same murmurHash3 invocation in TestIBLT/NameAppendAndExtract computes a hash value of 4138171066 on amd64 (a little-endian cpu) and a hash value of 397881680 on s390x (a big-endian cpu).
Updated by Junxiao Shi about 2 years ago
Updated by Davide Pesavento about 2 years ago
- Status changed from New to Code review
- Assignee set to Junxiao Shi
- Target version set to v0.4.0
- Start date deleted (
01/28/2019)