[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