<div dir="ltr"><div><div><div>(Pedantic: fontconfig isn't object oriented.)<br><br></div>Aside from that: I'm not quite sure what you're asking. As Akira pointed out, MD5 is only used for directory names. <br><br>
</div>Caches are versioned and there have been changes to the cache format. The programmatic fontconfig API to access the cache is public and fixed. For instance: <a href="http://freedesktop.org/software/fontconfig/fontconfig-devel/fcdircacheload.html">http://freedesktop.org/software/fontconfig/fontconfig-devel/fcdircacheload.html</a><br>
<br></div>pat<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 6:56 PM, L. A. Walsh <span dir="ltr"><<a href="mailto:fonts@tlinx.org" target="_blank">fonts@tlinx.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Behdad Esfahbod wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On 14-06-20 02:13 PM, L. A. Walsh wrote:<br>
  <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On x86_64 machines, when addressing the cache, if all types were<br>
listed as being "[u]int{32,64}_t", when wouldn't the cache format<br>
on such machines be identical whether you were running in 32-bit<br>
or 64-bit mode?<br>
<br></div><div class="">
The separate caches are mandated by the public API that cannot be changed anymore<br>
    <br>
</div></blockquote></blockquote>
Why would a *temporary* cache be part of a public API that cannot be changed?<br>
I'm more than a bit astonished that someone would think that a cache should<br>
be part of a public API?   Why would anyone do that?<br>
<br>
Where is the object oriented design?  How can the format be upgraded or<br>
improved?<br>
<br>
Who (or what product) is a "consumer" of the API?  Why would<br>
some other application outside of the library need fixed access to<br>
an internal cache format?  Are you saying that if someone finds a way<br>
to create a security exploit using this public cache API that cannot change,<br>
then there would be no way to fix it?<br>
<br>
Caches are usually (in my experience, always), private data stores that<br>
speed access.  Example -- squid has a cache, but it would never be part of a<br>
public API, as a cache, by definition, is supposed to be something that is for<br>
"fast and private access".   The kernel has multiple caches -- but in a<br>
20+ year old product, they don't have any public API to internal caches that<br>
would ever be called stable.  Why does a font library need to publish a fixed<br>
cache format?<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Fontconfig mailing list<br>
<a href="mailto:Fontconfig@lists.freedesktop.org" target="_blank">Fontconfig@lists.freedesktop.<u></u>org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/fontconfig" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/fontconfig</a><br>
</div></div></blockquote></div><br></div>