>> 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?