The other maintainer suddenly disappeared.
(cherry picked from commit 77a294d98a9d2d48f7e4ac273711518bf689f5c4)
(cherry picked from commit 37c46f7b67feddc164f227273770121412038ee2)
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)
(cherry picked from commit 64e0a5f726c483bdda2ee35ed7ae5f515278272f)
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)
(cherry picked from commit 203d48259935bad1c26e35d42f3db3c0f414bd8c)
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)
(cherry picked from commit 214569ace8ebb34a853cdc958ac7117c8051fe03)
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)
(cherry picked from commit b03139b1d210865526ab0e945aa79b2627f8c202)
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)
(cherry picked from commit 08754772e801218e5e06dc06e51c9e712ddf3e49)
NVHPC compiler has several issues that make it impossible to
build liblzma:
- 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)
(cherry picked from commit 65ac20807c1303e80fb8fc28ec810d740078e328)
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)
(cherry picked from commit 78a015e753d40d604952d6c1e4428c5f440ea6b9)
This is to match configure.ac.
(cherry picked from commit 025eb6d7879e4c4e8cb29716b371e0f4c1aea660)
(cherry picked from commit bcac3e3aa29d476e38a8722d687776cdbac1f3dc)
The AC_MSG_ERROR line is overlong anyway as are a few other
AC_MSG_ERROR lines already.
(cherry picked from commit 45d33bfc45e4295b8ad743bc2ae61cc724f98076)
(cherry picked from commit 9e7daa8dbdc38f32696b6ec90cb4ba4ca49fa6cc)
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)
(cherry picked from commit ce3a9fa94d6092665c3b000dc0dbe9a2900d4df2)
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)
(cherry picked from commit 7d3418e496d00287d08a7f5af265379b757247a6)
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)
(cherry picked from commit 65b5ee071697e4fe4c2a31c14c1d68b727f1654c)
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)
(cherry picked from commit 402fb45c743b736fa033b4b04881f6d1098581fd)
This makes "less" show a warning if a decompression error occurred.
(cherry picked from commit fd0692b0525e6c26b496492be9e2c865cab734f8)
(cherry picked from commit 5e7a8c0869d9b4c32c34d70b48b0935721aa37fd)
This is unlikely to be a bug in an existing application since it relies
on calling lzma_filters_update() on an LZMA1 encoder in the first place.
For instance, it does not affect xz because lzma_filters_update() can
only be used when encoding to the .xz format.
(based on commit 8191720eac950a5db89c4d33d6beea6316a49b19)
lzma_raw_encoder() and lzma_raw_encoder_init() used "options" as the
parameter name instead of "filters" (used by the declaration). "filters"
is more clear since the parameter represents the list of filters passed
to the raw encoder, each of which contains filter options.
(cherry picked from commit 27ab54af848ec4adc9c17362f6c64a42a7003df5)
lzma_encoder_init() did not check for NULL options, but
lzma2_encoder_init() did. This is more of a code style improvement than
anything else to help make lzma_encoder_init() and lzma2_encoder_init()
more similar.
(cherry picked from commit 019afd72e02339a6bf00c32bfb56f649c637dd6b)
The new is_tty() will report if a file descriptor is a terminal or not.
On POSIX systems, it is a wrapper around isatty(). However, the native
Windows implementation of isatty() will return true for all character
devices, not just terminals. So is_tty() has a special case for Windows
so it can use alternative Windows API functions to determine if a file
descriptor is a terminal.
This fixes a bug with MSVC and MinGW-w64 builds that refused to read from
or write to non-terminal character devices because xz thought it was a
terminal. For instance:
xz foo -c > /dev/null
would fail because /dev/null was assumed to be a terminal.
(cherry picked from commit 0ecfaa6df91f7c37510f370295f593b9c0b88b98)
The macro lzma_attr_visibility_hidden has to be defined to make
fastpos.h usable. The visibility attribute is irrelevant to
fastpos_tablegen.c so simply #define the macro to an empty value.
fastpos_tablegen.c is never built by the included build systems
and so the problem wasn't noticed earlier. It's just a standalone
program for generating fastpos_table.c.
Fixes: https://github.com/tukaani-project/xz/pull/69
Thanks to GitHub user Jamaika1.
(cherry picked from commit d90ed84db9770712e2421e170076b43bda9b64a7)
In ELF shared libs:
-fvisibility=hidden affects definitions of symbols but not
declarations.[*] This doesn't affect direct calls to functions
inside liblzma as a linker can replace a call to lzma_foo@plt
with a call directly to lzma_foo when -fvisibility=hidden is used.
[*] It has to be like this because otherwise every installed
header file would need to explictly set the symbol visibility
to default.
When accessing extern variables that aren't defined in the
same translation unit, compiler assumes that the variable has
the default visibility and thus indirection is needed. Unlike
function calls, linker cannot optimize this.
Using __attribute__((__visibility__("hidden"))) with the extern
variable declarations tells the compiler that indirection isn't
needed because the definition is in the same shared library.
About 15+ years ago, someone told me that it would be good if
the CRC tables would be defined in the same translation unit
as the C code of the CRC functions. While I understood that it
could help a tiny amount, I didn't want to change the code because
a separate translation unit for the CRC tables was needed for the
x86 assembly code anyway. But when visibility attributes are
supported, simply marking the extern declaration with the
hidden attribute will get identical result. When there are only
a few affected variables, this is trivial to do. I wish I had
understood this back then already.
(cherry picked from commit 6961a5ac7df178bfc2b7a181c40575847bc3035f)
MinGW (formely a MinGW.org Project, later the MinGW.OSDN Project
at <https://osdn.net/projects/mingw/>) has GCC 9.2.0 as the
most recent GCC package (released 2021-02-02). The project might
still be alive but majority of people have switched to MinGW-w64.
Thus it seems clearer to refer to MinGW-w64 in our API headers too.
Building with MinGW is likely to still work but I haven't tested it
in the recent years.
(cherry picked from commit 5b9e16764905d06fa8e8339ba185ddfee304e5fb)
A CMake option LARGE_FILE_SUPPORT is created if and only if
-D_FILE_OFFSET_BITS=64 affects sizeof(off_t).
This is needed on many 32-bit platforms and even with 64-bit builds
with MinGW-w64 to get support for files larger than 2 GiB.
(cherry picked from commit 36fabdbe67c8a8fbdc3ac695a91fc443a1328cc4)
It properly adds -DLZMA_API_STATIC when compiling code that
will be linked against static liblzma. Having it there on
systems other than Windows does no harm.
See: https://www.msys2.org/docs/pkgconfig/
(cherry picked from commit 4083c8e9501a48934a5fb563d2c3ce2ae143cd27)
Both PREFIX and IMPORT_PERFIX have to be set to "" to get
liblzma.dll and liblzma.dll.a.
(cherry picked from commit da4d04e4d6e199d28b58bd2e0df4e120c52dd5d7)
Updating from version 6 -> 8 from upstream. Declarations for variables
and function bodies were added to avoid unnecessary failures with
-Werror.
(cherry picked from commit 4cc91ceb3992ef4f51302b56178c3b2c2aeaaaad)
llvm-windres 17.0.0 has more accurate emulation of GNU windres, so
the hack for GNU windres must now be used with llvm-windres too.
LLVM 16.0.6 has the old behavior and there likely won't be more
16.x releases. So we can simply check for >= 17.0.0.
The workaround must not be used with Clang that is acting in
MSVC mode. This checks for the known environments that need
the workaround instead of using "NOT MSVC".
See also:
2bcc0fdc58
(cherry picked from commit 38171492ded6426ddf53d0c200fa8c93fcd02a60)
