Peter Marschall wrote:

...

...

  For the big-endian case, 'msg' wasn't set from 'tval' in generate().

This patch is wrong, as I commented on github.

Are you sure?

Please note the run index i changed direction, which causes different results because of >>=.

In my tests [double checked before sending this mail] on an amd64 [little- endian architecture], the patched version converts 0x3837363534333231 to

• "87654321" in the !WORDS_BIGENDIAN case [unchanged]
• "12345678" in the WORDS_BIGENDIAN case

[using the fact that 0x3N = "N" for 0 <= N <=9] To me that looks correct.

What issues did you see exactly?

That is exactly wrong. Given any integer input the string should be identical regardless of endianness. It should be "87654321" in both cases. With your patch, hashes will be incompatible between different machine architectures.