Clang 17 with -fsanitize=address,undefined:
src/liblzma/common/filter_common.c:366:8: runtime error:
call to function encoder_find through pointer to incorrect
function type 'const lzma_filter_coder *(*)(unsigned long)'
src/liblzma/common/filter_encoder.c:187: note:
encoder_find defined here
Use a wrapper function to get the correct type neatly.
This reduces the number of casts needed too.
This issue could be a problem with control flow integrity (CFI)
methods that check the function type on indirect function calls.
Fixes: 3b34851de1eaf358cf9268922fa0eeed8278d680
(cherry picked from commit 278563ef8f2b8d98d7f2c85e1a64ec1bc21d26d8)
It's undefined behavior. The result wasn't ever used as it occurred
in the last iteration of a loop.
Clang 17 with -fsanitize=address,undefined:
$ src/xz/xz --block-list=123
src/xz/args.c:164:12: runtime error: applying non-zero offset 1
to null pointer
Fixes: 88ccf47205d7f3aa314d358c72ef214f10f68b43
Co-authored-by: Sam James <sam@gentoo.org>
(cherry picked from commit 77c8f60547decefca8f2d0c905d9c708c38ee8ff)
On LZMA_DATA_ERROR from lzma_index_buffer_decode(), *i = NULL was
already done but this adds a test for that case too.
(cherry picked from commit 575b11b0d291e66c5fce31ce7a72f11436d57c83)
liblzma guarantees that the product of the allocation size arguments
will fit in size_t.
Putting the pre-increment in the if-statement was clearly wrong
although in practice it didn't matter here as the function is
called only a couple of times.
(cherry picked from commit 7f865577a6224fbbb5f5ca52574b62ea8ac9bf51)
If the arguments to lzma_index_decoder() or lzma_index_buffer_decode()
were such that LZMA_PROG_ERROR was returned, the lzma_index **i
argument wasn't touched even though the API docs say that *i = NULL
is done if an error occurs. This obviously won't be done even now
if i == NULL but otherwise it is best to do it due to the wording
in the API docs.
In practice this matters very little: The problem can occur only
if the functions are called with invalid arguments, that is,
the calling application must already have a bug.
(cherry picked from commit 71eed2520e2eecae89bade9dceea16e56cfa2ea0)
The API docs clearly say that if error_pos isn't NULL then *error
is always set on any error. However, it wasn't touched if str == NULL
or filters == NULL or unsupported flags were specified.
Fixes: cedeeca2ea6ada5b0411b2ae10d7a859e837f203
(cherry picked from commit 70d12dd069bb9bb0d6bb1c8fafc4e6f77780263d)
This does the previous commit with CMake.
AC_EGREP_CPP uses AC_REQUIRE so the outermost if-commands must
be changed to AS_IF to ensure that things wont break some day.
See 5a5bd7f871818029d5ccbe189f087f591258c294.
(cherry picked from commit 49324b711f9d42b3543bf2f3ae598eaa03360bd5)
It doesn't support the __symver__ attribute or __asm__(".symver ...").
The generic symbol versioning can still be used since it only needs
linker support.
(cherry picked from commit c273123ed0ebaebf49994057a7fe98aae7f42c40)
NVHPC compiler has several issues that make it impossible to
build liblzma:
- the compiler cannot handle unions that contain pointers that
are not the first members;
- the compiler fails to produce valid code for delta_decode if the
vectorization is enabled, which results in failed tests.
This introduces NVHPC-specific workarounds that address the issues.
(This commit was contributed under 0BSD but the author confirmed
that it is fine to backport it to the public domain branches. See
https://github.com/tukaani-project/xz/pull/90#issuecomment-2100185936
and the next two messages.)
(cherry picked from commit 096bc0e3f8fb4bfc4d2f3f64a7f219401ffb4c31)
This better matches what configure.ac does. For example, musl has
only basic symbol versioning support:
https://wiki.musl-libc.org/functional-differences-from-glibc.html#Symbol_versioning
configure.ac tries to enable symbol versioning only with glibc
so now CMake does the same.
(cherry picked from commit 2ad7fad67080e88fa7fc191f9d613d8b7add9c62)
The AC_MSG_ERROR line is overlong anyway as are a few other
AC_MSG_ERROR lines already.
(cherry picked from commit 45d33bfc45e4295b8ad743bc2ae61cc724f98076)
There are cases when the users want to decide themselves whether
they want to have the generic (even on GNU/Linux) or the linux
(even if we do not recommend that) symbol versioning variant.
The former might be needed to circumvent compiler issues (i.e.
the compiler does not support all features that are required
for the linux versioning), the latter might help in overriding
the assumptions made in the configure script.
(This commit was contributed under 0BSD but the author confirmed
that it is fine to backport it to the public domain branches. See
https://github.com/tukaani-project/xz/pull/90#issuecomment-2100185936
and the next two messages.)
(cherry picked from commit f56ed6fac6619b56b005878d3b5210e2f0d721c0)
Also explicitly initialize progress_automatic to make it clear
that it can be read before message_init() sets it. Static variable
was initialized to false by default already so this is only for
clarity.
(cherry picked from commit c701a5909ad9882469fbab4fab5d2d5556d3ba78)
It was added in 2017 in c2e29f06a7d1e3ba242ac2fafc69f5d6e92f62cd
but it never got into any release tarballs because it was
forgotten to be added to Makefile.am.
(cherry picked from commit dfdb60ffe933a1f1497d300dbb4513ed17ec6f0e)
It is built and run only manually so this didn't matter
unless one wanted to regenerate the price_table.c.
(cherry picked from commit 8e4ec794836bc1701d8c9bd5e347b8ce8cc5bbb4)
The initial commit 5d018dc03549c1ee4958364712fb0c94e1bf2741
in 2007 had a comment in sha256.c that the code is based on
Crypto++ Library 5.5.1. In 2009 the Authors list in sha256.c
and the AUTHORS file was updated with information that the
code had come from Crypto++ but via 7-Zip. I know I had viewed
7-Zip's SHA-256 code but back then the C code has been identical
enough with Crypto++, so I don't why I thought the author info
would need that extra step via 7-Zip for this single file.
Another error is that I had mixed sha.* and shacal2.* files
when checking for author info in Crypto++. The shacal2.* files
aren't related to liblzma's sha256.c and thus Kevin Springle's
code in Crypto++ isn't either.
(cherry picked from commit 76946dc4336c831fe2cc26696a035d807dd3cf13)
