Peter Marschall wrote:
Hi,
On Sunday, 30. August 2015 23:58:09 Howard Chu wrote:
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.
Please read my mail again! I tested the WORDS_BIGENDIAN case on a *little-endian* architecture using the same data as the !WORDS_BIGENDIAN case.
In that case [i.e. testing on the "wrong-endian" architecture] the result *is expected* to come out in reversed order. Otherwise it would end-up in wrong order on the "right-endian" architecture.
Do you agree?
The point is that your patch *always* reverses the order of the bytes. On a big-endian machine the code should be a no-op.
If you don't, please hint me to some code that allows me to check and fix my code.
Best Peter