MD5 checksum? Why? And why is there stuff to switch little endien?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

#define byteReverse(buf, len)    /* Nothing */
* 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);

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?

Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux