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


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



_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig




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

  Powered by Linux