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

L. A. Walsh fonts at tlinx.org
Fri Jun 20 15:56:25 PDT 2014

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

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 
cache format?

More information about the Fontconfig mailing list