fix misaligned pointer use in hash code

[jwwalker]

The MurmurHash code was using misaligned pointers, which is undefined behavior according to the C++ standard and probably unsafe on multiple platforms. See Is it well-defined to hold a misaligned pointer, as long as you don't ever dereference it? on Stack Overflow.

[darksylinc]

My biggest concern is performance. MurmurHash was considered for its speed. This patch:

• Replaces a raw cast with a copy (via memcpy) that may or may not be optimized (likely not, due to the visibility constraints)
• Replaces uint32_t/uint64_t ptrs for uint8_t which has a different performance profile due to strict aliasing rules

Sounds like we should analyze the feasibility of feeding aligned-ptrs-only instead:

1. malloc allocations are already guaranteed to be aligned (unless offseted of course)
2. Stack allocations are aligned to whatever the data is. It's "usually aligned" to what we need, but it may need a stricter enforcement
3. Data coming from structures should have the proper OGRE_ALIGNED_DECL
4. Using OGRE_ASSERT_HIGH( isAligned( key ) ); is completely acceptable
5. Using compiler extensions to diagnose alignment is also fine

I tried using OGRE_ASSERT_HIGH( isAligned( key ) ); with:

inline bool isAligned( const uint8_t *x )
{
return (reinterpret_cast<size_t>(x) & 0xFu) == 0u;
}

and it did not trigger; but a simple "works on my machine" (Linux x64) isn't a scientific measurement.

If it's unfeasible to feed aligned ptrs, then we have no other choice but to bite the bullet.

Alternative:

Brainstorming here:

Having 2 versions of the routine and dispatch based on ptr alignment may be an interesting approach; ideally only used on platforms where unaligned reads are actually unsupported (though that's UB)

[jwwalker]

To give a specific example, I'm getting odd addresses passed to the hash function by IdString( const std::string &string ).

[eugenegff]

That is a real bug in MurmurHash3 code. It is hidden by the fact that x86/x64/arm64 allows unaligned reads, but should explode on arm32 and maybe other platforms. Other problem is with aliasing - casting (uint8*) to (uint32*) is already UB, as it allows compiler to assume things that are not true and then optimize basing on those assumptions. Moreover, similar problem was found with storing results in (uint32_t)out = h1;

Others found this issue too, https://discourse.julialang.org/t/problem-with-issue-murmurhash3-has-undefined-behavior/9807 and I highly recommend to read that thread with justification of using memcpy compiler intrinsic to solve both issues - alignment and aliasing. Here is their fix https://github.com/JuliaLang/julia/pull/30220/files

Unfortunately, problems are not fixed in upstream https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp
and last changes to sources were made 9 years ago.

[darksylinc]

Using a different hash algorithm is not out of the question.

There have been newer hashing algos since Murmur came out.