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.
Passing -Wno-pointer-bool-conversion in cross file
to suppress compiler warning:
src/fcfreetype.c:1373:11: address of array 'os2->achVendID' will always evaluate to 'true'
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');
^~~~
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.
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.
Some systems build FreeType using CMake rather than autotools (such as Visual
Studio), which will give us CMake config files rather than pkg-config files, so
if we can't find FreeType using pkg-config, try again using CMake.
Please note that according to FreeType's docs/VERSIONS.TXT, the version we want
when checking with CMake is 2.8.1 or later.
Tim-Philipp Müller
Ben Wagner
Xavier Claessens
Carmina16
Szunti
Jacko Dirks
ratijas
Akira TAGOH
Niklas Guertler
Chun-wei Fan
Nirbheek Chauhan
xiota
James Lee