On Fri, June 20, 2014 06:10, L. A. Walsh wrote: > [...] > I'd never seen byte order switching w/an MD5 algorithm before, and > checked against wikipedia. The one there doesn't seem to do any > endian switching -- AND of more concern, the constants, (the same > ones in the font-config code), the input and the output are all described > as being little endian. So why is there code to switch endianness?: All code that casts the same buffer to char and int interchangeably needs to be aware of endianness. >From RFC1321: " The implementation is portable and should work on many different plaforms. However, it is not difficult to optimize the implementation on particular platforms, an exercise left to the reader. For example, on "little-endian" platforms where the lowest-addressed byte in a 32- bit word is the least significant and there are no alignment restrictions, the call to Decode in MD5Transform can be replaced with a typecast. " This means MD5 assumes the input data can be regarded as series of little-endian int's. On platforms where it can't, a conversion step is necessary. To avoid that, the implementation in the RFC reads the input bytewise and shifts it into int's. Colin Plumb's implementation, which fontconfig uses, seems to cast a char buffer to an int one, mandating an endianness check. Raimund -- Worringer Str 31 Duesseldorf 40211 DE home: <rs@xxxxxxxx> +49-179-2981632 icq 16845346 work: <rs@xxxxxxxxxxxxxxx> _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/fontconfig
