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 __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)
The array could become empty and then the initializer would be
simply {} which is allowed only in GNU-C and C23.
(cherry picked from commit b101e1d1dbc81577c0c9aa0cb89cf2e46a15eb82)
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 few lines were reordered, a few ARRAY_SIZE were changed to sizeof,
and a few uint32_t were changed to size_t. No real functional changes
were intended.
(cherry picked from commit 0fe2dfa68355d2b165544b2bc8babf77dcc2039e)
hw.ncpu counts all CPUs including inactive ones. hw.activecpu counts
only the active CPUs.
(cherry picked from commit 97f0ee0f1f903f4e7c4ea23e9b89d687025d2992)
We discussed the name and it's less cognitive load to just call it '.bash'
so you don't have an immediate question about if bashisms are OK.
(cherry picked from commit 73f629e321b74f68c9954728fa4f19261afccf46)
We need this for when we're passing sanitizer flags or -gdwarf-4 for Clang
with Valgrind. Just always start with -O2 if CFLAGS isn't set in the
environment and append what was passed on the command line.
(cherry picked from commit 65bf7e0a1ca6386f17608e8afb84ac470c18d23f)
This is a lot easier to work with than the save-logs thing the action
tries to do...
(cherry picked from commit bc899f9e0700ad153bd65f4804c4de7515c8a847)
Unfortunately, UBSAN doesn't do this by default. See also the change
I made in Meson for this in October [0].
[0] 7b7d2e060b
(cherry picked from commit b5e3470442531717b2457b40ab412740296af1bc)
Using `--trace-children=yes` has a trade-off here, as it makes
`test_scripts.sh` pretty slow when calling various non-xz utilities.
But I also feel like it's not useless to have Valgrind used there and it's
not easy to exclude Valgrind just for that one test...
I did consider using AX_VALGRIND_CHECK [0][1] but I couldn't get it working
immediately with some conditionally-built tests and I wondered if it was
worth spending time on at least while we're debating xz's future build
system situation.
[0] https://www.gnu.org/software/autoconf-archive/ax_valgrind_check.html
[1] https://tecnocode.co.uk/2014/12/23/automatically-valgrinding-code-with-ax_valgrind_check/
(cherry picked from commit 6c095a98fbec70b790253a663173ecdb669108c4)
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)
This can speed up configure a tiny bit.
Fixes: c5f6d79cc9515a7f22d7ea4860c6cc394b295732
(cherry picked from commit 308a9af85400b0e2019f0f012c8354e831d06d65)
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)
