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? If you don't, please hint me to some code that allows me to check and fix my code. Best Peter -- Peter Marschall [email protected]
