Sometimes we might want to build docs (install man pages, etc)
but allow disabling use of docbook.
Bug: https://bugs.gentoo.org/310157
Signed-off-by: Sam James <sam@gentoo.org>
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.
Previously, requesting a monospace font with an invalid font family
(for instance, when a font is not embedded in a PDF, poppler may
issue such queries), the font family would be filled by configuration
file 49-sansserrif.conf with sans-serif
This new rule set the family to monospace if spacing=100 is specified
in the query.
The version_compare() block is redundant because we require meson 0.56
now, and it fixes a spurious warning:
```
fontconfig| WARNING: Project targeting '>= 0.53' but tried to use feature introduced in '0.54.0': list_sep arg in summary.
```
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
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.
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.
Bump the cache version to avoid unexpected behavior in
older version of fontconfig.
There was no real incompatible features introduced in a cache.
But the older version of fontconfig can't deal with variable fonts
and then it failed. To avoid this breakage, you may want to choose
one of options like:
1) Applying this change to fontconfig in host and remove all the
fontconfig caches and then regenerate them by fc-cache linked with
older one and new one. or simply run applications.
You'll see two versions of caches in the cache directories.
2) Remove variable fonts on system and remove all the fontconfig
caches too. then regenerate caches. You'll still see one version of
caches there but without the entries of variable fonts.
After that, the problem should be gone.
https://bugzilla.redhat.com/show_bug.cgi?id=1981500
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.
Jeremy Huddleston Sequoia
Alan Coopersmith
Sam James
Taylor R Campbell
Akira TAGOH
Francesco Pretto
Pierre Ducroquet
Nirbheek Chauhan
Akira TAGOH
Ben Wagner
Ryan Gonzalez
Behdad Esfahbod
Ryan Schmidt
Alex Richardson