tests.cmake checked DECODERS instead of XZ_DECODERS. With
XZ_MICROLZMA_DECODER=OFF, test_microlzma was incorrectly added
to the list of tests, which resulted in a build failure.
Closes: https://github.com/tukaani-project/xz/pull/255
This can matter on Windows:
- MSVC puts the binaries into subdirectories based on build type
(like "Debug" or "Release"), and then the test executables won't
find liblzma.dll because it's not in the working directory from
which the tests are run.
- With mingw-w64, liblzma.dll was in the working directory so the test
executables worked. However, the if the system happened to have
liblzma.dll in, for example, the Windows directory, then the DLL
search order might pick that instead.
Putting the shared library and test executables in the same directory
avoids these problems.
Reported-by: Frank <mail@franku.nl>
Fixes: https://github.com/tukaani-project/xz/pull/239
It was (probably) intentionally without the null terminator, but the test
works with null terminator too (the test still fails with xz <= 5.0.3),
so simply omit one character to silence the warning.
tests/test_bcj_exact_size.c:30:32: error: initializer-string for array of ‘unsigned char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (17 chars into 16 available) [-Werror=unterminated-string-initialization]
30 | const uint8_t in[16] = "0123456789ABCDEF";
| ^~~~~~~~~~~~~~~~~~
Fixes: d8db706acb83 ("liblzma: Fix possibility of incorrect LZMA_BUF_ERROR.")
Fixes: https://github.com/tukaani-project/xz/issues/176
This makes it easy to crash fuzz_decode_stream_mt when tested
against the code from 5.8.0.
Obviously this might make it harder to reach some other code path now.
The previous code has been in use since 2018 when fuzzing was added
in 106d1a663d4b ("Tests: Add a fuzz test program and a config file
for OSS-Fuzz.").
It doesn't seem possible to trigger the CVE-2025-31115 bug with this
fuzzing target at the moment. It's because the code in fuzz_common.h
passes the whole input buffer to lzma_code() at once.
Now "crc32" is in the list too for completeness but it doesn't
actually have any effect. The description of the cache variable
says that "crc32 is always built" so it should be clear enough.
Now the test scripts detect both
#define HAVE_DECODER_ARM
#define HAVE_DECODER_ARM 1
as support for the ARM filter without confusing it with these:
#define HAVE_DECODER_ARM64
#define HAVE_DECODER_ARM64 1
Previously only the ones ending with " 1" were accepted for
the macros where this kind of confusion was possible.
This should help with Meson support because Meson's built-in
features produce config.h entries that are either
#define FOO 1
#define FOO 0
or:
#define FOO
#undef FOO
The former method has a benefit that one can use "#if FOO" and -Wundef
will catch if a #define is missing (for example, it helps catching
typos). But XZ Utils has to use the latter since it has been
convenient with Autoconf's default behavior.[*] While it's easy to
emulate the Autoconf style (#define FOO 1 vs. no #define at all)
in Meson, it results in clumsy code. Thus it's better to change
the few places in the tests where this difference matters.
[*] While most checks in Autoconf default to the second style above,
a few things use the first style (like AC_CHECK_DECLS). The mix
of both styles is the most confusing as one has to remember which
macro needs #ifdef and which #if. Currently HAVE_VISIBILITY is
only such config.h entry that is 1 or 0. It comes unmodified
from Gnulib's visibility.m4.
Add a new optional argument to specify the directory of the xz and
xzdec executables.
If ../config.h doesn't exist, assume that all encoders and decoders
are available.
Add a new optional second argument: directory of the xz and xzdec
executables. This is need with the CMake build where the binaries
end up in the top-level build directory.
If ../config.h doesn't exist, assume that all encoders and decoders
are available. This will make this script usable from CMake in the
most common build configuration.
NOTE: Since the existence of ../config.h is checked, the working
directory of the test script must be a subdir in the build tree!
Otherwise ../config.h would look outside the build tree.
Use the default check type instead of forcing CRC32 or CRC64.
Now the script doesn't need to check if CRC64 is available.
This is a bit hacky since the scripts grep config.h to know which
features were built but the CMake build doesn't create config.h.
So instead those test scripts will be run only when all relevant
features have been enabled.
