ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
Otherwise it won't correctly escape things like spaces, and can print
out the `\` literal escaping nothing, which causes most shell lexers to
choke.
Fixes: #238
AC_CHECK_FUNCS is not safe, since implicit function definitions is just
a warning. On 64-bit glibc systems where reallocarray is not defined or
hidden behind macros that are not set, it gets implicitly defined to
return an integer, which is a big problem given that it should return a
pointer, and leads to immediate segfaults.
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
fix https://github.com/pkgconf/pkgconf/issues/291
As defined in the C standard:
In all cases the argument is an int, the value of which shall
be representable as an unsigned char or shall equal the value
of the macro EOF. If the argument has any other value, the
behavior is undefined.
This is because they're designed to work with the int values returned
by getc or fgetc; they need extra work to handle a char value.
If EOF is -1 (as it almost always is), with 8-bit bytes, the allowed
inputs to the ctype(3) functions are:
{-1, 0, 1, 2, 3, ..., 255}.
However, on platforms where char is signed, such as x86 with the
usual ABI, code like
char *ptr = ...;
... isspace(*ptr) ...
may pass in values in the range:
{-128, -127, -126, ..., -2, -1, 0, 1, ..., 127}.
This has two problems:
1. Inputs in the set {-128, -127, -126, ..., -2} are forbidden.
2. The non-EOF byte 0xff is conflated with the value EOF = -1, so
even though the input is not forbidden, it may give the wrong
answer.
Casting char to unsigned int first before passing the result to
ctype(3) doesn't help: inputs like -128 are unchanged by this cast,
because (on a two's-complement machine with 32-bit int and unsigned
int), converting the signed char with integer value -128 to unsigned
int gives integer value 2^32 - 128 = 0xffffff80, which is out of
range, and which is converted in int back to -128, which is also out
of range.
It is necessary to cast char inputs to unsigned char first; you can
then cast to unsigned int if you like but there's no need because the
functions will always convert the argument to int by definition. So
the above fragment needs to be:
char *ptr = ...;
... isspace((unsigned char)*ptr) ...
This patch changes unsigned int casts to unsigned char casts, and
adds unsigned char casts where they are missing.
The code taken from rpmvercmp in pkg-config returns -1 if a is less than
b, 0 if a is equal to b, and 1 if a is greater than b. This matches the
expectations of the comparison operators that use this function.
However, the tilde handling, the NULL handling, and the docstring all do
the opposite.
This fixes the tilde handling, the NULL handling, and the docstring to
match the behavior of the rpmvercmp code and the expectations of the
comparison operators.
Given the following .pc fragment:
includedir=/mingw64/include
Cflags: -I${includedir} -I${includedir}/taglib
Should includedir be assigned the value 'C:/Program\ Files/Git/mingw64/include', the expansion of ${includedir} will be chopped off after the first space:
Cflags: -IC:/Program\
With this patch, the expansion is corrected:
Cflags: -IC:/Program\ Files/Git/mingw64/include -IC:/Program\ Files/Git/mingw64/include/taglib
Create spaces-in-paths.pc
otherwise a buffer overflow occurs.
this has been a bug in pkgconf since the beginning, it seems.
instead of disclosing the bug correctly, a "hotshot" developer
decided to blog about it instead. sigh.
https://nullprogram.com/blog/2023/01/18/
ci/woodpecker/pr/woodpecker Pipeline was successfulDetails
This allows tests to be autodetected gracefully, which is particularly
convenient for kyua and atf_sh which are fairly painful to build and
install by hand. Those who want to ensure tests are enabled or disabled
may pass `-Dtests=enabled` or `-Dtests=disabled` respectively.
This does require a modest bump in the required meson version to 0.49,
which was released at the end of 2018, so roughly 4 years ago.