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?
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
