[Fontconfig] MD5 checksum? Why? & mmap alignment on same machine in 32.v.64 mode

L. A. Walsh fonts at tlinx.org
Fri Jun 20 11:13:28 PDT 2014

Raimund Steger wrote:
> 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.
    In other words, it appears that the shuffling routine should NOT
compiled-in on little-endian machines because of:

#define byteReverse(buf, len)    /* Nothing */

I.e. HIGHFIRST would be false on a little endian machine.  Yes?
I'm a bit rusty on my define macro expansion, but wouldn't

Second Q, the reason for needing separate caches has been described
as being due to the desire to mmap the cache files.

On x86_64 machines, when addressing the cache, if all types were
listed as being "[u]int{32,64}_t", when wouldn't the cache format
on such machines be identical whether you were running in 32-bit
or 64-bit mode?

I.e. it seems that when reading(or writing) values, you would explicitly
need to know that you needed a 32 or 64 bit quantity.  The only difference
between 32 & 64 bit modes that I know of is in regards to [unsigned]long 
where, at least in c++, it's a 64-bit size on x64 vs. 32-bit on x32.  I have
some vague remembrence that a [uns]long-int in 'C' is 32-bits in both
on some OS's (don't remember if it was MS-only or both MS+linux && no-idea
on Mac).  Either way, wouldn't it be the case that one size (32 or 64) 
would be
needed, so referring to data members with the bitsize should result in 
mmap'ed structures on x86_64 whether you are running in 32 or 64
bit mode?

Wouldn't that require using only 1 cache on those machines?


More information about the Fontconfig mailing list