summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump version and soname for 5.2.12.v5.2.12v5.2Jia Tan2023-05-042-2/+2
|
* Add NEWS for 5.2.12.Jia Tan2023-05-041-0/+14
|
* Translations: Update the Croatian translation.Jia Tan2023-05-041-2/+2
|
* tuklib_integer.h: Fix a recent copypaste error in Clang detection.Lasse Collin2023-05-031-2/+2
| | | | | | Wrong line was changed in 7062348bf35c1e4cbfee00ad9fffb4a21aa6eff7. Also, this has >= instead of == since ints larger than 32 bits would work too even if not relevant in practice.
* Update THANKS.Jia Tan2023-05-031-0/+1
|
* Windows: Include <intrin.h> when needed.Jia Tan2023-05-032-0/+16
| | | | | | | | | | Legacy Windows did not need to #include <intrin.h> to use the MSVC intrinsics. Newer versions likely just issue a warning, but the MSVC documentation says to include the header file for the intrinsics we use. GCC and Clang can "pretend" to be MSVC on Windows, so extra checks are needed in tuklib_integer.h to only include <intrin.h> when it will is actually needed.
* tuklib_integer: Use __builtin_clz() with Clang.Jia Tan2023-05-031-3/+3
| | | | | | | | | Clang has support for __builtin_clz(), but previously Clang would fallback to either the MSVC intrinsic or the regular C code. This was discovered due to a bug where a new version of Clang required the <intrin.h> header file in order to use the MSVC intrinsics. Thanks to Anton Kochkov for notifying us about the bug.
* liblzma: Update project maintainers in lzma.h.Lasse Collin2023-05-031-1/+1
| | | | AUTHORS was updated earlier, lzma.h was simply forgotten.
* liblzma: Cleans up old commented out code.Jia Tan2023-05-031-11/+0
|
* Build: Removes redundant check for LZMA1 filter support.Jia Tan2023-05-031-4/+1
|
* Build: Add a comment that AC_PROG_CC_C99 is needed for Autoconf 2.69.Lasse Collin2023-03-211-0/+3
| | | | | It's obsolete in Autoconf >= 2.70 and just an alias for AC_PROG_CC but Autoconf 2.69 requires AC_PROG_CC_C99 to get a C99 compiler.
* Build: configure.ac: Use AS_IF and AS_CASE where required.Lasse Collin2023-03-211-8/+8
| | | | | | | This makes no functional difference in the generated configure (at least with the Autotools versions I have installed) but this change might prevent future bugs like the one that was just fixed in the commit 5a5bd7f871818029d5ccbe189f087f591258c294.
* Update THANKS.Lasse Collin2023-03-211-0/+1
|
* Build: Fix --disable-threads breaking the building of shared libs.Lasse Collin2023-03-211-8/+8
| | | | | | | | | | | | | | | | | | | | | | | This is broken in the releases 5.2.6 to 5.4.2. A workaround for these releases is to pass EGREP='grep -E' as an argument to configure in addition to --disable-threads. The problem appeared when m4/ax_pthread.m4 was updated in the commit 6629ed929cc7d45a11e385f357ab58ec15e7e4ad which introduced the use of AC_EGREP_CPP. AC_EGREP_CPP calls AC_REQUIRE([AC_PROG_EGREP]) to set the shell variable EGREP but this was only executed if POSIX threads were enabled. Libtool code also has AC_REQUIRE([AC_PROG_EGREP]) but Autoconf omits it as AC_PROG_EGREP has already been required earlier. Thus, if not using POSIX threads, the shell variable EGREP would be undefined in the Libtool code in configure. ax_pthread.m4 is fine. The bug was in configure.ac which called AX_PTHREAD conditionally in an incorrect way. Using AS_CASE ensures that all AC_REQUIREs get always run. Thanks to Frank Busse for reporting the bug. Fixes: https://github.com/tukaani-project/xz/issues/45
* Bump version and soname for 5.2.11.v5.2.11Jia Tan2023-03-182-2/+2
|
* Add NEWS for 5.2.11.Jia Tan2023-03-181-0/+27
|
* Update the copy of GNU GPLv3 from gnu.org to COPYING.GPLv3.Lasse Collin2023-03-181-4/+4
|
* Change a few HTTP URLs to HTTPS.Lasse Collin2023-03-188-19/+19
| | | | The xz man page timestamp was intentionally left unchanged.
* CMake: Require that the C compiler supports C99 or a newer standard.Lasse Collin2023-03-111-0/+8
| | | | | | Thanks to autoantwort for reporting the issue and suggesting a different patch: https://github.com/tukaani-project/xz/pull/42
* Update THANKS.Lasse Collin2023-03-111-0/+1
|
* liblzma: Avoid null pointer + 0 (undefined behavior in C).Lasse Collin2023-03-119-22/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the C99 and C17 standards, section 6.5.6 paragraph 8 means that adding 0 to a null pointer is undefined behavior. As of writing, "clang -fsanitize=undefined" (Clang 15) diagnoses this. However, I'm not aware of any compiler that would take advantage of this when optimizing (Clang 15 included). It's good to avoid this anyway since compilers might some day infer that pointer arithmetic implies that the pointer is not NULL. That is, the following foo() would then unconditionally return 0, even for foo(NULL, 0): void bar(char *a, char *b); int foo(char *a, size_t n) { bar(a, a + n); return a == NULL; } In contrast to C, C++ explicitly allows null pointer + 0. So if the above is compiled as C++ then there is no undefined behavior in the foo(NULL, 0) call. To me it seems that changing the C standard would be the sane thing to do (just add one sentence) as it would ensure that a huge amount of old code won't break in the future. Based on web searches it seems that a large number of codebases (where null pointer + 0 occurs) are being fixed instead to be future-proof in case compilers will some day optimize based on it (like making the above foo(NULL, 0) return 0) which in the worst case will cause security bugs. Some projects don't plan to change it. For example, gnulib and thus many GNU tools currently require that null pointer + 0 is defined: https://lists.gnu.org/archive/html/bug-gnulib/2021-11/msg00000.html https://www.gnu.org/software/gnulib/manual/html_node/Other-portability-assumptions.html In XZ Utils null pointer + 0 issue should be fixed after this commit. This adds a few if-statements and thus branches to avoid null pointer + 0. These check for size > 0 instead of ptr != NULL because this way bugs where size > 0 && ptr == NULL will likely get caught quickly. None of them are in hot spots so it shouldn't matter for performance. A little less readable version would be replacing ptr + offset with offset != 0 ? ptr + offset : ptr or creating a macro for it: #define my_ptr_add(ptr, offset) \ ((offset) != 0 ? ((ptr) + (offset)) : (ptr)) Checking for offset != 0 instead of ptr != NULL allows GCC >= 8.1, Clang >= 7, and Clang-based ICX to optimize it to the very same code as ptr + offset. That is, it won't create a branch. So for hot code this could be a good solution to avoid null pointer + 0. Unfortunately other compilers like ICC 2021 or MSVC 19.33 (VS2022) will create a branch from my_ptr_add(). Thanks to Marcin Kowalczyk for reporting the problem: https://github.com/tukaani-project/xz/issues/36
* Update THANKS.Lasse Collin2023-03-111-0/+1
|
* Build: Use only the generic symbol versioning on MicroBlaze.Lasse Collin2023-03-111-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On MicroBlaze, GCC 12 is broken in sense that __has_attribute(__symver__) returns true but it still doesn't support the __symver__ attribute even though the platform is ELF and symbol versioning is supported if using the traditional __asm__(".symver ...") method. Avoiding the traditional method is good because it breaks LTO (-flto) builds with GCC. See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 For now the only extra symbols in liblzma_linux.map are the compatibility symbols with the patch that spread from RHEL/CentOS 7. These require the use of __symver__ attribute or __asm__(".symver ...") in the C code. Compatibility with the patch from CentOS 7 doesn't seem valuable on MicroBlaze so use liblzma_generic.map on MicroBlaze instead. It doesn't require anything special in the C code and thus no LTO issues either. An alternative would be to detect support for __symver__ attribute in configure.ac and CMakeLists.txt and fall back to __asm__(".symver ...") but then LTO would be silently broken on MicroBlaze. It sounds likely that MicroBlaze is a special case so let's treat it as a such because that is simpler. If a similar issue exists on some other platform too then hopefully someone will report it and this can be reconsidered. (This doesn't do the same fix in CMakeLists.txt. Perhaps it should but perhaps CMake build of liblzma doesn't matter much on MicroBlaze. The problem breaks the build so it's easy to notice and can be fixed later.) Thanks to Vincent Fazio for reporting the problem and proposing a patch (in the end that solution wasn't used): https://github.com/tukaani-project/xz/pull/32
* liblzma: Fix documentation for LZMA_MEMLIMIT_ERROR.Jia Tan2023-03-111-1/+1
| | | | | LZMA_MEMLIMIT_ERROR was missing the "<" character needed to put documentation after a member.
* tuklib_physmem: Silence warning from -Wcast-function-type on MinGW-w64.Jia Tan2023-03-111-0/+18
| | | | | | | | tuklib_physmem depends on GetProcAddress() for both MSVC and MinGW-w64 to retrieve a function address. The proper way to do this is to cast the return value to the type of function pointer retrieved. Unfortunately, this causes a cast-function-type warning, so the best solution is to simply ignore the warning.
* xz: Add missing comment for coder_set_compression_settings()Jia Tan2023-03-111-1/+2
|
* xz: Do not set compression settings with raw format in list mode.Jia Tan2023-03-111-1/+2
| | | | | | | Calling coder_set_compression_settings() in list mode with verbose mode on caused the filter chain and memory requirements to print. This was unnecessary since the command results in an error and not consistent with other formats like lzma and alone.
* xz: Use ssize_t for the to-be-ignored return value from write(fd, ptr, 1).Lasse Collin2023-03-111-1/+1
| | | | | It makes no difference here as the return value fits into an int too and it then gets ignored but this looks better.
* liblzma: Silence warnings from clang -Wconditional-uninitialized.Lasse Collin2023-03-111-1/+1
| | | | | | | This is similar to 2ce4f36f179a81d0c6e182a409f363df759d1ad0. The actual initialization of the variables is done inside mythread_sync() macro. Clang doesn't seem to see that the initialization code inside the macro is always executed.
* Fix warnings from clang -Wdocumentation.Lasse Collin2023-03-113-8/+4
|
* xz: Fix warning -Wformat-nonliteral on clang in message.c.Jia Tan2023-03-111-0/+9
| | | | | clang and gcc differ in how they handle -Wformat-nonliteral. gcc will allow a non-literal format string as long as the function takes its format arguments as a va_list.
* CMake/Windows: Add a workaround for windres from GNU binutils.Lasse Collin2023-03-111-1/+31
| | | | | | | | | | This is combined from the following commits in the master branch: 443dfebced041adc88f10d824188eeef5b5821a9 6b117d3b1fe91eb26d533ab16a2e552f84148d47 5e34774c31d1b7509b5cb77a3be9973adec59ea0 Thanks to Iouri Kharon for the bug report, the original patch, and testing.
* CMake: Update cmake_minimum_required from 3.13...3.16 to 3.13...3.25.Lasse Collin2023-03-111-1/+1
| | | | | The changes listed on cmake-policies(7) for versions 3.17 to 3.25 shouldn't affect this project.
* Update THANKS.Lasse Collin2023-03-111-0/+1
|
* CMake: Fix a copypaste error in xzdec Windows resource file handling.Lasse Collin2023-03-111-2/+2
| | | | It was my mistake. Thanks to Iouri Kharon for the bug report.
* CMake/Windows: Add resource files to xz.exe and xzdec.exe.Lasse Collin2023-03-111-0/+16
| | | | | | | The command line tools cannot be built with MSVC for now but they can be built with MinGW-w64. Thanks to Iouri Kharon for the bug report and the original patch.
* liblzma: Update documentation for lzma_filter_encoder.Jia Tan2023-03-111-2/+5
|
* Doxygen: Update .gitignore for generating docs for in source build.Jia Cheong Tan2023-03-111-0/+2
| | | | | In source builds are not recommended, but we should still ignore the generated artifacts.
* CMake: Update .gitignore for CMake artifacts from in source build.Jia Tan2023-03-111-0/+23
| | | | | In source builds are not recommended, but we can make it easier by ignoring the generated artifacts from CMake.
* Bump version and soname for 5.2.10.v5.2.10Lasse Collin2022-12-132-2/+2
|
* Add NEWS for 5.2.10.Lasse Collin2022-12-131-0/+12
|
* Tests: Fix a typo in tests/files/README.Lasse Collin2022-12-131-1/+1
|
* Update AUTHORS.Lasse Collin2022-12-121-0/+4
|
* xz: Make args_info.files_name a const pointer.Lasse Collin2022-12-122-2/+2
|
* xz: Don't modify argv[].Lasse Collin2022-12-121-4/+19
| | | | | | | | The code that parses --memlimit options and --block-list modified the argv[] when parsing the option string from optarg. This was visible in "ps auxf" and such and could be confusing. I didn't understand it back in the day when I wrote that code. Now a copy is allocated when modifiable strings are needed.
* liblzma: Check for unexpected NULL pointers in block_header_decode().Lasse Collin2022-12-121-0/+4
| | | | | | | | | The API docs gave an impression that such checks are done but they actually weren't done. In practice it made little difference since the calling code has a bug if these are NULL. Thanks to Jia Tan for the original patch that checked for block->filters == NULL.
* liblzma: Use __has_attribute(__symver__) to fix Clang detection.Lasse Collin2022-12-121-1/+14
| | | | | | | | | | If someone sets up Clang to define __GNUC__ to 10 or greater then symvers broke. __has_attribute is supported by such GCC and Clang versions that don't support __symver__ so this should be much better and simpler way to detect if __symver__ is actually supported. Thanks to Tomasz Gajc for the bug report.
* Update THANKS (sync all from master).Lasse Collin2022-12-121-0/+8
|
* Bump version and soname for 5.2.9.v5.2.9Lasse Collin2022-11-302-2/+2
|
* Add NEWS for 5.2.9.Lasse Collin2022-11-301-0/+34
|
View Lorry Controller Status