[Fontconfig] MD5 checksum? Why? And why is there stuff to switch little endien?
L. A. Walsh
fonts at tlinx.org
Thu Jun 19 21:10:12 PDT 2014
I don't understand why font caches are being MD5 checksummed?
It's not like they are that security sensitive, and I don't see why such
an expensive technique is being used.
Also, in looking at the code, I see a byte order reversal for little ending
machines -- which I don't understand.
The caches aren't even portable between 32 and 64 bit caches on same
machine, so why is there byte-reversing going on for some compat w/
big endian machines when the caches aren't portable between archs?
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?:
#ifndef HIGHFIRST
#define byteReverse(buf, len) /* Nothing */
#else
/*
* Note: this code is harmless on little-endian machines.
*/
void byteReverse(unsigned char *buf, unsigned longs) {
FcChar32 t;
do {
t = (FcChar32) ((unsigned) buf[3] << 8 | buf[2]) << 16 |
((unsigned) buf[1] << 8 | buf[0]);
*(FcChar32 *) buf = t;
buf += 4;
} while (--longs);
}
#endif
--------------
Is that only for big endian machines? But does it make sense even there
given that the caches aren't portable?
Why are they being checksumed -- is it just to check for need to update?
Can't modification times be used for that?
More information about the Fontconfig
mailing list