On Sunday, 30. August 2015 23:58:09 Howard Chu wrote:
> Please note the run index i changed direction, which causes
> 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
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?
If you don't, please hint me to some code that allows me to check and fix my