The argument passed to each thread in test-pthread.c indicates a thread
number to report when finished. This value is read out by the thread
into a local variable early in the thread's execution. Currently, the
address passed as this argument is the address of a loop local. However,
it is possible that the created thread will not be scheduled to run or
will not read the argument before the thread creation loop finishes and
the local is destroyed. This can lead to odd behavior, usually observed
as multiple threads reporting the same thread_num.
Fix this issue by storing the thread arguments in a parallel array to
the array of threads. This ensures that the thread arguments are in
scope as long as the threads themselves.
Discovered with tests/test-pthread with AddressSanitizer enabled.
Non-string values in a cache is supposed to choose one from them.
Due to the change of da1c9f7a, there was a regression on scoring for
matching functions. So reverting the behavior for evaluating non-string
values to the previous one.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/286
Sometimes fonts has multiple values in family and sub-family in order to unify
other variants into one. they basically make difference in sub-family though,
they also still have standalone family and sub-family. in that case, sub-family is
likely to be Regular.
fontconfig couldn't recognize the difference between :family=Foo:style=Regular
and :family=Foo Caption:style=Regular for example because fontconfig didn't
give different score on matching result for the position of multiple values in
a cache.
Thus, when querying a font like :family=Foo:style=Regular may results
:family=Foo Caption:style=Regular. (see the test case for more details)
To fix this situation, giving different score according to the position
of multiple values in a cache as well as the position of multiple values
in a query.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/283
Discovered by AddressSanitizer. When left_o and right_o are promoted the
promoted values are placed on the stack in FcValuePromotionBuffer.
The FcValuePromotionBuffers must then continue to be in scope while
left_o and right_o point into their content. In 9d4e5d0f the
FcValuePromotionBuffers were moved into the incorrect scope, leaving
left_o and right_o pointing into an object whose lifetime has ended.
This is similar to left and right which appear to have a smaller scope
but are actually required to be in the larger scope.
Correct this by moving the FcValuePromotionBuffers to the proper scope.
Leave the left and right FcValues where they are since they are in the
correct scope already.
This also adds to test-conf the ability to create charset, langset,
range, and matrix in patterns. This allows for a simple test which fails
under AddressSanitizer before this change and passes after.
Correct the type of TestMatchPattern's 'ret' from TestResult to
TestMatchResult to match the actual return type (and values assigned to
it).
Fix leak of TestMatchPattern's 'xml' and TestFamily's 'pat'.
Simplify TestMatchPattern cleanup and ensure cleanup always happens.
Any early out checks must give the same answer as FcConfigCompareValue.
An accelerator was added for family names which treated all ops as if
they were FcOpEqual, giving the wrong answer for other non-equivalent ops
(for example FcOpContains or FcOpNotEqual).
This adds a test which passes before the accelerator was introduced,
fails after, and will pass again after !142 lands. This tests the all
not_eq case.
The test-conf build_pattern attempted to convert known constant strings
into integer values. However, it did so by always converting the string
value to an integer if possible and then complaining if the key wasn't
of the expected type. This lead to error messages on "style": "Regular"
since "Regular" was recognized as "weight".
Instead, only attempt conversion from string to integer if the key is
the name of an object which can take an integer type. This eliminates
the spurious non-fatal errors reported when parsing
test-90-synthetic.json.
This also fixes an issue where the created value was given the type of
the object found, but the integer field was assigned. Instead, check
that the object type can take an integer and always set the value type
to integer.
The test-conf test requires libjson-c to be available in order to be
built. However, there has been no user indication that additional tests
could be built if the json-c development files were available.
Continue to not build test-conf if json-c is not available, but do run
the test harness. The test harness is updated to SKIP the test if the
test-conf binary is unavailable.
Reported by AddressSanitizer when running test-conf. The `query`,
`result`, and `result_fs` were not initialized to NULL so could result
in a wild free when first initialized.
The `method` was also not initialized to NULL so comparisons could be
made against random data if it had not yet been assigned.
The outer `fs` was never destroyed, but is also not used, so remove.
Posix says:
The condition can be EXIT, 0 (equivalent to EXIT), or a signal
specified using a symbolic name, without the SIG prefix, as listed
in the tables of signal names in the <signal.h> header defined in
the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 13,
Headers; for example, HUP, INT, QUIT, TERM. Implementations may
permit names with the SIG prefix or ignore case in signal names as
an extension.
Remove 'SIG' from trap conditions in run-test.sh for portability.
Right now fontconfig uses a cache found first in a path and
cachedirs are the order of the system-wide path and then the user path.
this is due to avoid writing caches into the user path when running as root.
However, changing caches by certain config only, e.g. using <match target="scan">
may not take effect by this behavior, because it may be stored into the user path.
Thus, needing to find the latest cache out from paths.
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/182
cachedir is used to determine where cache files are stored.
the empty directory will ends up to put them under the top of
directory of XDG_CACHE_HOME. that messes it up and must be avoided.
As a note, if you want to read/write something from the top of
XDG_DATA_HOME (dir) and/or XDG_CACHE_HOME (cachedir),
put "." instead of the empty.
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/180
Currently it fails if the executable extension is .exe, but wine isn't
available (e.g. on Cygwin)
Possibly the check to use this wrapper should be even more restrictive
e.g. checking if cross-building and/or if wine is available.
'salt' attribute affects a cache filename to generate different name from directory name.
This is useful when sharing caches with host on sandbox and/or give a filename differently:
<dir salt="randomdata">/usr/share/fonts</dir>
<remap-dir as-path="/usr/share/fonts" salt="salt for /usr/share/fonts on host">/run/host/fonts</remap-dir>
Applications can read caches as-is for fonts on /run/host/fonts where is mounted from host.
and write a cache for their own fonts on /usr/share/fonts with different name.
The UUID files would be placed in each font directory to provide the
unique cache name, independent of path, for that directory. The UUID
files are undesireable for a couple of reasons:
1) They must be placed in the font directories to be useful. This
requires modifying the font directories themselves, introducing
potential visible timestamp changes when running multiple
applications, and makes the cache processing inconsistent between
applications with permission to write to the font directories and
applications without such permission.
2) The UUID contents were generated randomly, which makes the font
cache not reproducible across multiple runs.
One proposed fix for 2) is to make the UUID dependent on the font
directory path, but once we do that, we can simply use the font
directory path itself as the key as the original MD5-based font cache
naming mechanism did.
The goal of the UUID file mechanism was to fix startup time of
flatpaks; as the font path names inside the flatpak did not match the
font path names in the base system, the font cache would need to be
reconstructed the first time the flatpak was launched.
The new mechanism for doing this is to allow each '<dir>' element in
the configuration include a 'map' attribute. When looking for a cache
file for a particular directory, if the directory name starts with the
contents of the <dir> element, that portion of the name will be
replaced with the value of the 'map' attribute.
Outside of the flatpak, nothing need change -- fontconfig will build
cache files using real directory names.
Inside the flatpak, the custom fonts.conf file will now include
mappings such as this:
<dir map="/usr/share/fonts">/run/host/fonts</dir>
When scanning the directory /run/host/fonts/ttf, fontconfig will
use the name /usr/share/fonts/ttf as the source for building the cache
file name.
The existing FC_FILE replacement code used for the UUID-based
implementation continues to correctly adapt font path names seen by
applications.
v2:
Leave FcDirCacheCreateUUID stub around to avoid removing
public API function.
Document 'map' attribute of <dir> element in
fontconfig-user.sgml
Suggested-by: Akira TAGOH <akira@tagoh.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
On a file system with one-second time stamps, extra delays are needed
between cache modification operations to ensure that fontconfig isn't
fooled.
And, when the timestamps are checked correctly, we need to make sure
that FcConfigUptoDate returns false whenever we change a font
directory, so separate that out from the call to reinitialize the core
config.
Signed-off-by: Keith Packard <keithp@keithp.com>
This causes a failure when evaluating $OSTYPE on systems which do not
set that variable (everything but Msys/MinGW)
Signed-off-by: Keith Packard <keithp@keithp.com>
Akira TAGOH
Ben Wagner
Ryan Schmidt
Szunti
Niklas Guertler
Tim-Philipp Müller
Jon Turney
Keith Packard