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 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
