Recently some python scripts has been added to the build toolchain for meson build support. but we don't want to maintain multiple files for one purpose. since autotools build support will be guradually discontinued, integrating those scripts into autotools would be better.
This avoids a situation where the score of lang becomes lower or equal to others
and then figures out the best font according to other properties and the order
of family names.
This typically happens only when our orthography files are the subset of lang
in patterns. i.e. fc-match :lang=en-us to match on en.orth.
In this case, the score is lower than the exact match (en to en) and the partial
match (en to en-us). thus, the result of 'fc-match :lang=en-us' isn't necessarily
same to 'fc-match :lang=en'.
So 35-lang-normalize.conf contains languages only which is available as orth
without countries and tries to update properties to match on orth exactly like:
<match>
<test name="lang" compare="contains">
<string>en</string>
</test>
<edit name="lang" mode="assign" binding="same">
<string>en</string>
</edit>
</match>
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/155
The expression "1 << 31" will cause UBSAN to complain with this error message:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
The same operation on unsigned types is fine, however. This CL replaces the
strings "1 <<" with "1U <<".
FcLangSetIndex() contains code like this:
low = fcLangCharSetRanges[firstChar - 'a'].begin;
high = fcLangCharSetRanges[firstChar - 'a'].end;
/* no matches */
if (low > high)
The assumption behind this test didn't hold before this commit, unless
there is at least one language name that starts with 'z' (which is
thankfully the case in our world :-). If the last language name in
lexicographic order starts for instance with 'x', this change ensures
that fcLangCharSetRanges['y' - 'a'].begin and
fcLangCharSetRanges['z' - 'a'].begin
are equal to NUM_LANG_CHAR_SET, in order to make the above assumption
correct in all cases.
Code currently returns a fatal error if it tries to add more entries
than the array has room for, but it wasn't checking to make sure
the final null terminator entry would fit.
Reported by parfait 1.3:
Error: Buffer overrun
Buffer overflow (CWE 120): In array dereference of files[i] with index i
Array size is 256 elements (of 4 bytes each), index >= 0 and index <= 256
at line 250 of fc-glyphname/fc-glyphname.c in function 'main'.
Error: Buffer overrun
Buffer overflow (CWE 120): In array dereference of entries[i] with index i
Array size is 1024 elements (of 8 bytes each), index >= 0 and index <= 1024
at line 298 of fc-lang/fc-lang.c in function 'main'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Previously we were failing if CROSS_COMPILING and the generated headers
were not present. It works just fine now.
One caveat: the fix is not fully correct since config.h is being
included in the files built with CC_FOR_BUILD, but config.h has config
for the host system, not the build system. Should be fine though.
When ./configure'd in a directory other than the srcdir, we need to look
in ${top_builddir)/src for the generated header fcstdint.h
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Mike FABIAN
Akira TAGOH
Ryan Schmidt
Carmina16
Tim-Philipp Müller
Alan Coopersmith
Tom Anderson
Behdad Esfahbod
Florent Rougon
Jon TURNEY
Pravin Satpute
Parag Nemade
Pravin Satpute