Otherwise, PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR elements would be processed backwards.
Fixes: 384ade5 (path: prepend paths rather than append paths when processing --with-path arguments)
Closes: #250
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
There are numerous edge cases where version is wrong or missing when
matching the dependency queue to resolved packages. This adds the
dependency name as it appears in the dependency queue to each package as
it is resolved, allowing for a simple and correct comparison when
printing.
Signed-off-by: Colin Gillespie <colin@cgillespie.xyz>
Previously, --modversion operated on the calculated solution and printed versions in
order of the calculated dependency graph. Change this to use the dependency queue
instead, looking up nodes in the dependency graph as needed, to ensure that the
--modversion output behaves as intended.
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
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.
It turns out there was already a check for PKG_CFLAGS being requested,
but the check was busted because PKG_CFLAGS is a combined-or of all of
the various --cflags flags.
Check that PKG_CFLAGS bits are set at all on want_flags instead.
On Windows, pkgconf redefines the prefix by default.
This gives the user the option to disable this behavior via an environment variable.
The benefit of an environment variable is the user can change this behavior when
using a build system such as cmake or meson, which may not expose this
parameter to the user.