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.