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.
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.
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.
Akira TAGOH
Ben Wagner