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

[L. A. Walsh]

Behdad Esfahbod wrote:
> On 14-06-20 02:13 PM, L. A. Walsh wrote:
>   
>> 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?
>>
>> The separate caches are mandated by the public API that cannot be changed anymore
>>     
Why would a *temporary* cache be part of a public API that cannot be 
changed?
I'm more than a bit astonished that someone would think that a cache should
be part of a public API?   Why would anyone do that?

Where is the object oriented design?  How can the format be upgraded or
improved?

Who (or what product) is a "consumer" of the API?  Why would
some other application outside of the library need fixed access to
an internal cache format?  Are you saying that if someone finds a way
to create a security exploit using this public cache API that cannot change,
then there would be no way to fix it?

Caches are usually (in my experience, always), private data stores that
speed access.  Example -- squid has a cache, but it would never be part of a
public API, as a cache, by definition, is supposed to be something that 
is for
"fast and private access".   The kernel has multiple caches -- but in a
20+ year old product, they don't have any public API to internal caches that
would ever be called stable.  Why does a font library need to publish a 
fixed
cache format?