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