It's more logical to do it in the beginning instead of in the middle
of the filter chain handling.
Fixes: d6af7f347077b22403133239592e478931307759
(cherry picked from commit 32500dfaadae2ea36fda2e17b49ae7d9ac1acf52)
The convention is that
lzma_filter filters[LZMA_FILTERS_MAX + 1];
contains the filters of a single filter chain.
It was so here as well before the commit
d6af7f347077b22403133239592e478931307759.
It changes "filters" to a ten-element array of filter chains.
It's clearer to call this array-of-arrays "chains".
This also renames "filter_idx" to "chain_idx" which is used
as an index as in chains[chain_idx].
(cherry picked from commit ad146b1f42bbb678175a503a45ce525e779f9b8b)
opt_mode == MODE_COMPRESS isn't possible when HAVE_ENCODERS isn't
defined. Thus, when *encoding*, the message about *decoder* memory
usage is possible to show only when both encoder and decoder have
been built.
Since the message is shown only at V_DEBUG, skip the memusage
calculation if verbosity level isn't high enough.
Fixes: 5f0c5a04388f8334962c70bc37a8c2ff8f605e0a
(cherry picked from commit 347b412a9374e0456bef9da0d7d79174c0b6f1a5)
lzma_options_lzma.dict_size is uint32_t so use it here too.
Fixes: 5f0c5a04388f8334962c70bc37a8c2ff8f605e0a
(cherry picked from commit 31358c057c9de9d6aba96bae112b2d17942de7cb)
It likely was a leftover from a development version of the code.
Fixes: 183819bfd9efac8c184d9bf123325719b7eee30f
(cherry picked from commit fe4d8b0c80eaeca3381be302eeb89aba871a7e7c)
This was added to xz in 02e3505991233901575b7eabc06b2c6c62a96899
but I forgot to do the same in xzdec.
The Landlock sandbox in xzdec could be stricter as now it's
active only for the last file being decompressed. In xz,
read-only sandbox is used for multi-file case. On the other hand,
xz doesn't go to the strictest mode when processing the last file
when more than one file was specified; xzdec does.
(cherry picked from commit 3334c71d3d4294a4f6569df3ba9bcf2443dfa501)
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)
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 __builtin_bswapXX from GCC and Clang are preferred when
they are available. This can allow compilers to emit the x86 MOVBE
instruction instead of doing a load + byteswap as two instructions
(which would happen if the byteswapping is done in inline asm).
bswap16, bswap32, and bswap64 exist in system headers on *BSDs
and Darwin. #defining bswap16 on NetBSD results in a warning about
macro redefinition. It's safest to avoid this namespace conflict
completely.
No OS supported by tuklib_integer.h uses byteswapXX names and
a web search doesn't immediately find any obvious danger of
namespace conflicts. So let's try these still-pretty-short names
for the macros.
Thanks to Sam James for pointing out the compiler warning on
NetBSD 10.0.
(cherry picked from commit 4ffc60f32397371769b7d6b5e3ed8626292d58df)
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)
It is logical why it cannot know for sure that the value has
to be at most 4 if it is less than 16.
The x86 filter is based on a very old LZMA SDK version. Newer
ones have quite a different implementation for the same filter.
Thanks to Sam James.
(cherry picked from commit 6aa2a6deeba04808a0fe4461396e7fb70277f3d4)
On macOS, we get:
```
signals.c: In function 'signals_init':
signals.c:76:17: error: conversion to 'sigset_t' {aka 'unsigned int'} from 'int' may change the sign of the result [-Werror=sign-conversion]
76 | sigaddset(&hooked_signals, sigs[i]);
| ^~~~~~~~~
signals.c:81:17: error: conversion to 'sigset_t' {aka 'unsigned int'} from 'int' may change the sign of the result [-Werror=sign-conversion]
81 | sigaddset(&hooked_signals, message_progress_sigs[i]);
| ^~~~~~~~~
signals.c:86:9: error: conversion to 'sigset_t' {aka 'unsigned int'} from 'int' may change the sign of the result [-Werror=sign-conversion]
86 | sigaddset(&hooked_signals, SIGTSTP);
| ^~~~~~~~~
```
We use `int` for `hooked_signals` but we can't just cast to whatever
`sigset_t` is because `sigset_t` is an opaque type. It's an unsigned int
on macOS. On macOS, `sigaddset` is implemented as a macro.
Just suppress -Wsign-conversion for `signals_init` for macOS given
there's no real nice way of fixing this.
(cherry picked from commit 863f13d2828b99b0539ce73f9cf85bde32358034)
A macro is useful to prevent a single #if directive from
getting too ugly but only one macro is needed for all archs.
(cherry picked from commit 6286c1900c2d2ca33d9b1b397122c7bcdb9a4d59)
The macro name had an odd typo so the table wasn't omitted
when it should have.
Fixes: 1940f0ec28f08c0ac72c1413d9706fb82eabe6ad
(cherry picked from commit 45da936c879acf4f053a3055665bf1b10ded4462)
I didn't test this but it shouldn't change any functionality.
Fixes: 761f5b69a4c778c8bcb09279b845b07c28790575
(cherry picked from commit fc43cecd32bf9d5f8caa599206b15c9569af1eb6)
Also add parenthesis to the return statement.
I didn't test this.
Fixes: 761f5b69a4c778c8bcb09279b845b07c28790575
(cherry picked from commit 1024cd4cd966b998fedec51e385e9ee9a49b3c57)
Subtracting from 0 is negation, this just keeps warnings away.
Fixes: 761f5b69a4c778c8bcb09279b845b07c28790575
(cherry picked from commit 2337f7021c860b026e3e849e60a9ae8d09ec0ea0)
This is *NOT* done for security reasons even though the backdoor
relied on the ifunc code. Instead, the reason is that in this
project ifunc provides little benefits but it's quite a bit of
extra code to support it. The only case where ifunc *might* matter
for performance is if the CRC functions are used directly by an
application. In normal compression use it's completely irrelevant.
(cherry picked from commit 689ae2427342a2ea1206eb5ca08301baf410e7e0)
