The ctype(3) functions take arguments of type int that are either
(a) EOF, or
(b) unsigned char values, {0, 1, 2, ..., 255} if char is 8-bit.
Passing values of type char, on platforms where it is signed, can go
wrong -- negative values may be confused with EOF (typically -1) or
may lead to undefined behaviour ranging in practice from returning
garbage data (possibly out of an adjacent buffer in memory that may
contain secrets) to crashing with SIGSEGV (if the page preceding the
ctype table is unmapped).
The ctype(3) functions can't themselves convert to unsigned char
because then they would give the wrong answers for EOF, for use with
functions like getchar and fgetc; the user has to cast char to
unsigned char.
Trying to early loading a custom fonts.xml created on the
fly results in the pGetSystemWindowsDirectory function
pointer being found intialized. Normally the initialization
is performed in the default configuration loading.
The commit factorizes the lazy initialization of both
WIN32 getters (together with pSHGetFolderPathA) in a
function and call it when actually needed.
Because the loop body is just 'break' the loop never loops and at most
one leading space is skipped. Remove the body to allow the loop to
continue. Found with ClangTidy.
Instead of fixed number of buckets with chaining use an open addressing
hash table with linear probing, max load factor 0.75, and a power of two
number of buckets.
In particular, if an stdlib header goes first, it includes features.h
which only checks _FILE_OFFSET_BITS *once*, meaning that these files end
up compiled *without* _FILE_OFFSET_BITS taking effect, which affects
fcxml's operations in listing directories.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
When a config file is symlinked and obtaining an relative path from it for <dir>,
it behaved like:
$ realpath /path/to/foo.conf
/path/to/realpath/foo.conf
$ FONTCONFIG_FILE=/path/to/foo.conf fc-cache -v
Font directories:
/path/to/fonts
/path/to/fonts: skipping, existing cache is valid: 1 fonts, 0 dirs
/path/to/cachedir: cleaning cache directory
fc-cache: succeeded
And after this change:
$ FONTCONFIG_FILE=/path/to/foo.conf fc-cache -v
Font directories:
/path/to/relpath/fonts
/path/to/realpath/fonts: skipping, existing cache is valid: 1 fonts, 0 dirs
/path/to/cachedir: cleaning cache directory
fc-cache: succeeded
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/290
Before this fix:
$ fc-match :postscriptname=LiberationSans
LiberationSansNarrow.ttf: "Liberation Sans Narrow" "Regular"
After this fix:
$ fc-match :postscriptname=LiberationSans
LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
See https://bugzilla.redhat.com/show_bug.cgi?id=1946871
If two threads attempt to create the FcCache lock in lock_cache at the
same time, both threads may create and initialize a local FcMutex. One
thread will atomically make cache_lock point to its FcMutex. The other
thread currently calls FcMutexFinish on the local lock, but does not
free it. Change this behavior to free the unused lock.
Found with test/test-pthread on an LeakSanitizer enabled build.
Reduce the strength of the C11 atomics from memory_order_seq_cst to the
actually required memory order constraints for each operation. In
addition to reflecting the already documented memory order constraints,
this should allow for better code generation.
If the `realloc(numbers)` call fails, shrinking the leaves allocation
back to the old size is not guaranteed to return the old pointer value.
While this might be the case with some malloc() implementations, realloc()
could also just mark the following area as free.
To make this less error-prone, we grow numbers first and then grow leaves
since the numbers content does not need to be relocated, but leaves does.
See https://bugs.freedesktop.org/show_bug.cgi?id=90867
This fixes deprecation warnings when building for macOS >= 10.12 systems.
Additionally, using stdatomic.h (or the more modern __atomic_ builtins)
is required when targeting CHERI-enabled architectures such as
CHERI-RISC-V or Arm's Morello since the compiler rejects __sync_* atomic
for pointer types (they only work with integers).
When targeting CHERI, casts between pointers and integers must use
(u)intptr_t. uintptr_t values contains pointer bounds (and additional
metadata), whereas other integer types do not. This change also adds a
cast to FcOffsetToPtr() to silence a compiler warning that triggers if
the compiler cannot statically infer which side of an arithmetic operation
is the pointer operand and which one is the offset/mask.
Reverts the part of 6def66164a that
removed the fc_atomic_ptr_cmpexch compatibility code for systems earlier
than Mac OS X 10.5.
Reverts the part of 447b9ccc7d that moved
the definition of fc_atomic_ptr_get into the Mac OS X > 10.4 block. That
code is still needed on 10.4 and is implemented using functions that are
available on 10.4.
Compare against MAC_OS_X_VERSION_MIN_REQUIRED using a number not a
constant because the constant is not available on earlier SDKs.
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
commit ae9ac2a1 from !165 introduced a regression when
fontconfig is built as a subproject. In that case we
would fail to correctly construct the path to the root
build dir where the meson-info subdirectory resides,
instead looking for it in the fontconfig subproject
subdir. This would result in
FAILED: subprojects/fontconfig/src/fcobjshash.gperf
errors in the cutout.py script.
Instead use the @BUILD_ROOT@ substitution to get
to the build root which will work correctly in
either scenario.
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.
Pass c_args to the compiler when preprocessing the gperf header file,
they might contain important bits without which compilation/preprocessing
might fail (e.g. with clang on Android). cc.cmd_array() does not include
the c_args and we can't easily look them up from the meson.build file, so
we have to retrieve from the introspection info.
This is basically the Meson equivalent to commit 57103773.
fcformat.c:762:44: warning: expression which evaluates to zero treated as a null pointer constant of type 'FcChar8 *' (aka 'unsigned char *') [-Wnon-literal-null-conversion]
if (!FcNameUnparseValue (buf, &l->value, '\0'))
^~~~
fcformat.c:769:38: warning: expression which evaluates to zero treated as a null pointer constant of type 'FcChar8 *' (aka 'unsigned char *') [-Wnon-literal-null-conversion]
FcNameUnparseValueList (buf, l, '\0');
^~~~
There doesn't appear to be a good reason to abort when 'v1' has type
FcTypeRange. If there does turn out to be a good reason for this then it
should be better documented and the code for handling this case removed.
At worst it seems -1 should be returned as it is for other unknown
types. It is possible this is left over debug code from the initial
implementation.
Found by Clang-Tidy. The intent seems to have been to skip all leading
whitespace in the 'style' string, but instead this loop was an odd
looking no-op. Remove the 'break' from the loop so that it will
continue until end of string or a non-space character is found.
There seems to be a lot of config files using fullname property in the world.
To keep the backward compatibility, fullname property is back to a cache at
the scan matching phase but will be rebuilt once it is done according to family
and style property in the pattern no matter what changes one made in fullname
property during that.
Ref. https://bugzilla.redhat.com/show_bug.cgi?id=1902881
Instead, when building with Visual Studio-style compilers, define 'FcPublic' as
appropriate so that symbols will be exported without the need to maintain a
.def file.
To work around a warning with GCC10 on Win32
warning: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Wstringop-overflow=]
Before this change building with ThreadSanitizer and running
test/test-pthread generated a large number of threading issues. These
mostly stemmed from fc_atomic_ptr_get not doing an atomic load and using
"acquire load" instead of "load acquire". After making these changes it
was still necessary to use fc_atomic_ptr_get where it was needed.
This also documents the current memory barrier requirements for the
atomic primitives.
Akira TAGOH
Taylor R Campbell
Francesco Pretto
Akira TAGOH
Ben Wagner
Ryan Gonzalez
Behdad Esfahbod
Alex Richardson
Ryan Schmidt
Mehdi Sabwat
Albert Astals Cid
Tim-Philipp Müller
Szunti
Jacko Dirks
Niklas Guertler
Chun-wei Fan
Xavier Claessens