GPerf seems not allowing the empty lines though, current recipes are supposed to drop them.
but seems not working on some env.
So taking the proper way to do that instead of incompatible things against platforms.
FcFontSetFont() accesses fs->fonts in that macro though, there was no error checks
if it is null or not.
As a result, there was a code path that it could be a null.
Even though this is unlikely to see in usual use, it might be intentionally created
in a cache.
So if fs->fonts is a null, we should consider a cache is invalid.
FcConfigRealFilename() follows symlinks, but the link may be relative to the
directory containing the link. For example, on my system, I have this file:
/etc/fonts/conf.d/99-language-selector-zh.conf ->
../conf.avail/99-language-selector-zh.conf
Since /etc/fonts/conf.d is probably not in PATH, open()ing the file would fail.
This change makes FcConfigRealFilename() return the canonicalized filename
instead. So for the example above, it would return:
/etc/fonts/conf.avail/99-language-selector-zh.conf
This was causing bad font rendering in Chromium [1] after the regression I
introduced in 7ad010e80b.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=857511
CFI [1] is a dynamic analysis tool that checks types at runtime. It reports an
error when using a function with signature eg. (void (*)(char*)) as
(void (*)(void*)). This change adds some wrapper functions to avoid this issue.
In optimized builds, the functions should get optimized away.
[1] https://clang.llvm.org/docs/ControlFlowIntegrity.html
This changes the rewriting of the FC_FILE values for relocated caches to an earlier stage
while reading the cache. This is better, because it means all APIs will report the
rewritten paths, not just the once that use the list apis.
We do this by detecting the relocated case and duplicating the FcPattern and FcPatternElm
in an cache allocation (which will die with the cache) and then reusing the FcValueLists
from the cache.
This means that in the rewritten case we will use some more memory, but not the full
size of the cache. In a test here I had 800k of relocated caches, but ~200k of wasted
on duplicating the objects.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=106618
Whilst working on the Reproducible Builds[0] effort, we noticed that
fontconfig generates unreproducible cache files.
This is due to fc-cache uses the modification timestamps of each
directory in the "checksum" and "checksum_nano" members of the _FcCache
struct. This is so that it can identify which cache files are valid
and/or require regeneration.
This patch changes the behaviour of the checksum calculations to prefer
the value of the SOURCE_DATE_EPOCH[1] environment variable over the
directory's own mtime. This variable can then be exported by build
systems to ensure reproducible output.
If SOURCE_DATE_EPOCH is not set or is newer than the mtime of the
directory, the existing behaviour is unchanged.
This work was sponsored by Tails[2].
[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://tails.boum.org/
realfilename is the file name after sysroot adjustments. It should be used
instead of filename in the call to FcOpen() which forwards the name directly to
open().
Though I don't explicitly request a sysroot, I was getting error messages saying
"failed reading config file". This CL fixes the error spam.
The expression "1 << 31" will cause UBSAN to complain with this error message:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
The same operation on unsigned types is fine, however. This CL replaces the
strings "1 <<" with "1U <<".
Akira TAGOH
Tom Anderson
Behdad Esfahbod
Matthieu Herrb
Alexander Larsson
Chris Lamb