Windows: Document the need for setlocale(LC_ALL, ".UTF8")

Also warn about unpaired surrogates and (somewhat UTF-8-specific)
MAX_PATH issue in FindFirstFileA().

Fixes: 46ee0061629fb075d61d83839e14dd193337af59

xzdec: Call tuklib_progname_init() early enough

If the early pledge() call on OpenBSD fails, it calls my_errorf()
which requires the "progname" variable.

Fixes: d74fb5f060b76db709b50f5fd37490394e52f975

CMake: Bump maximum policy version to 3.31

With CMake 3.31, there were a few warnings from
CMP0177 "install() DESTINATION paths are normalized".
These occurred because the install(FILES) command in
my_install_man_lang() is called with a DESTINATION path
that contains two consecutive slashes, for example,
"share/man//man1". Such a path is for the English man pages.
With translated man pages, the language code goes between
the slashes. The warning was probably triggered because the
extra slash gets removed by the normalization.

Update THANKS

liblzma: Fix incorrect macro name in a comment

Fixes: 33b8a24b6646a9dbfd8358405aec466b13078559
Closes: https://github.com/tukaani-project/xz/pull/155

license-check.sh: Add an exception for doc/SHA256SUMS

Fixes: 36b531022f24a2ab57a2dfb9e5052f1c176e9d9a

doc/SHA256SUMS: Add the list of SHA-256 hashes of release files

The release files are signed but verifying the signatures cannot
catch certain types of attacks:

1. A malicious maintainer could make more than one variant of
   a package. One could be for general distribution. Another
   with malicious content could be targeted to specific users,
   for example, distributing the malicious version on a mirror
   controlled by the attacker.

2. If the signing key of an honest maintainer was compromised
   without being detected, a similar situation as described
   above could occur.

SHA256SUMS could be put on the project website but having it in
the Git repository makes it obvious that old lines aren't modified
when the file is updated.

Hashes of uncompressed files are included too. This way tarballs
can be recompressed and the hashes can still be verified.

Docs: Remove .github/SECURITY.md

One of the reasons to have this file in the xz repository was to
show vulnerability reporting info in the Security section on GitHub.
On 2024-11-25, I added SECURITY.md to the tukaani-project organization
on GitHub:

    https://github.com/tukaani-project/.github/blob/main/SECURITY.md

GitHub shows that file in all projects in the organization unless
overridden by a project-specific SECURITY.md. Thus, removing
the file from the xz repo makes GitHub show the organization-wide
text instead.

Maintaining a single copy for the whole GitHub organization makes
things simpler. It's also nicer to have fewer GitHub-specific files
in the xz repo. Information how to report bugs (including security
issues) is available in README and on the home page too.

The OpenSSF Scorecard tool didn't find .github/SECURITY.md from the
xz repository. There was a suggestion to move the file to the top-level
directory where Scorecard should find it. However, Scorecard does find
the organization-wide SECURITY.md. Thus, the file isn't needed in the
xz repository to score points in the Scorecard game:

    https://scorecard.dev/viewer/?uri=github.com/tukaani-project/xz

Closes: https://github.com/tukaani-project/xz/issues/148
Closes: https://github.com/tukaani-project/xz/pull/149

Translations: Update the Chinese (traditional) translation

liblzma: Optimize the loop conditions in BCJ filters

Compilers cannot optimize the addition "i + 4" away since theoretically
it could overflow.

Update THANKS

xz: Landlock: Fix a file descriptor leak

CI: update FreeBSD, NetBSD, OpenBSD, Solaris actions

Checked the changes and they're all innocuous. This should hopefully
fix the "externally managed" pip error in these jobs that started
recently.

Add NEWS for 5.6.3

cmake/tuklib_large_file_support.cmake: Add a missing include

v5.2 didn't build with CMake. Other branches had
include(CMakePushCheckState) in top-level CMakeLists.txt
which made the build work.

Fixes: 597f49b61475438a43a417236989b2acc968a686

Update THANKS

Tests/Windows: Add the application manifest to the test programs

This ensures that the test programs get executed the same way as
the binaries that are installed.

license-check.sh: Add an exception for w32_application.manifest

The file gets embedded as is into executables, thus it cannot
hold a license identifier.

Windows: Embed an application manifest in the EXE files

IMPORTANT: This includes a security fix to command line tool
           argument handling.

Some toolchains embed an application manifest by default to declare
UAC-compliance. Some also declare compatibility with Vista/8/8.1/10/11
to let the app access features newer than those of Vista.

We want all the above but also two more things:

  - Declare that the app is long path aware to support paths longer
    than 259 characters (this may also require a registry change).

  - Force the code page to UTF-8. This allows the command line tools
    to access files whose names contain characters that don't exist
    in the current legacy code page (except unpaired surrogates).
    The UTF-8 code page also fixes security issues in command line
    argument handling which can be exploited with malicious filenames.
    See the new file w32_application.manifest.comments.txt.

Thanks to Orange Tsai and splitline from DEVCORE Research Team
for discovering this issue.

Thanks to Vijay Sarvepalli for reporting the issue to me.

Thanks to Kelvin Lee for testing with MSVC and helping with
the required build system fixes.

Windows: Set DLL name accurately in StringFileInfo on Cygwin and MSYS2

Now the information in the "Details" tab in the file properties
dialog matches the naming convention of Cygwin and MSYS2. This
is only a cosmetic change.

common_w32res.rc: White space edits

LANGUAGE and VS_VERSION_INFO begin new statements so put an empty line
between them.

CMake: Add the resource files to the Cygwin and MSYS2 builds

Autotools-based build has always done this so this is for consistency.

However, the CMake build won't create the DEF file when building
for Cygwin or MSYS2 because in that context it should be useless.
(If Cygwin or MSYS2 is used to host building of normal Windows
binaries then the DEF file is still created.)

CMake: Fix Windows resource file dependencies

If common_w32res.rc is modified, the resource files need to be rebuilt.
In contrast, the liblzma*.map files truly are link dependencies.

CMake: Checking for CYGWIN covers MSYS2 too

On MSYS2, both CYGWIN and MSYS are set.

Translations: Add the SPDX license identifier to pt_BR.po

Windows/CMake: Use the correct resource file for lzmadec.exe

CMakeLists.txt was using xzdec_w32res.rc for both xzdec and lzmadec.

Fixes: 998d0b29536094a89cf385a3b894e157db1ccefe

Translations: Update the Brazilian Portuguese translation

Update THANKS

lzmainfo: Avoid integer overflow

The MB output can overflow with huge numbers. Most likely these are
invalid .lzma files anyway, but let's avoid garbage output.

lzmadec was adapted from LZMA Utils. The original code with this bug
was written in 2005, over 19 years ago.

Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>
Closes: https://github.com/tukaani-project/xz/pull/144

xzdec: Remove unused short option -M

"xzdec -M123" exited with exit status 1 without printing
any messages. The "M:" entry should have been removed when
the memory usage limiter support was removed from xzdec.

Fixes: 792331bdee706aa852a78b171040ebf814c6f3ae
Closes: https://github.com/tukaani-project/xz/pull/143
[ Lasse: Commit message edits ]

Update THANKS

Build: Fix a typo in autogen.sh

Fixes: e9be74f5b129fe8a5388d588e68b1b7f5168a310
Closes: https://github.com/tukaani-project/xz/pull/141

Translations: Update Chinese (simplified) translation

Differences to the zh_CN.po file from the Translation Project:

  - Two uses of \v were fixed.

  - Missing "OPTS" translation in --riscv[=OPTS] was copied from
    previous lines.

  - "make update-po" was run to remove line numbers from comments.

Translations: Update the Catalan translation

Differences to the ca.po file from the Translation Project:

  - An overlong line translating --filters-help was wrapped.

  - "make update-po" was used to remove line numbers from the comments
    to match the changes in fccebe2b4fd513488fc920e4dac32562ed3c7637
    and 093490b58271e9424ce38a7b1b38bcf61b9c86c6. xz.pot in the TP
    is older than these commits.

Update THANKS

CMake: Don't install lzmadec.1 symlinks if XZ_TOOL_LZMADEC=OFF

Thanks-to: 榆柳松 (ZhengSen Wang) <wzhengsen@gmail.com>
Fixes: fb50c6ba1d4c9405e5b12b5988b01a3002638c5d
Closes: https://github.com/tukaani-project/xz/pull/134

CMake: Fix the build when XZ_TOOL_LZMADEC=OFF

Co-developed-by: 榆柳松 (ZhengSen Wang) <wzhengsen@gmail.com>
Fixes: fb50c6ba1d4c9405e5b12b5988b01a3002638c5d
Fixes: https://github.com/tukaani-project/xz/pull/134

Update THANKS

liblzma: Fix x86-64 movzw compatibility in range_decoder.h

Support for instruction "movzw" without suffix in "GNU as" was
added in commit [1] and stabilized in binutils 2.27, released
in August 2016. Earlier systems don't accept this instruction
without a suffix, making range_decoder.h's inline assembly
unable to build on old systems such as Ubuntu 16.04, creating
error messages like:

    lzma_decoder.c: Assembler messages:
    lzma_decoder.c:371: Error: no such instruction: `movzw 2(%r11),%esi'
    lzma_decoder.c:373: Error: no such instruction: `movzw 4(%r11),%edi'
    lzma_decoder.c:388: Error: no such instruction: `movzw 6(%r11),%edx'
    lzma_decoder.c:398: Error: no such instruction: `movzw (%r11,%r14,4),%esi'

Change "movzw" to "movzwl" for compatibility.

[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c07315e0c610e0e3317b4c02266f81793df253d2

Suggested-by: Lasse Collin <lasse.collin@tukaani.org>
Tested-by: Yifeng Li <tomli@tomli.me>
Signed-off-by: Yifeng Li <tomli@tomli.me>
Fixes: 3182a330c1512cc1f5c87b5c5a272578e60a5158
Fixes: https://github.com/tukaani-project/xz/issues/121
Closes: https://github.com/tukaani-project/xz/pull/136

Build: Comment that elf_aux_info(3) will be available on OpenBSD >= 7.6

Revert "liblzma: Add ARM64 CRC32 instruction support detection on OpenBSD"

This reverts commit dc03f6290f5b9bd3d50c7e12e58dee870889d599.

OpenBSD 7.6 will support elf_aux_info(3), and the detection code used
on FreeBSD will work on OpenBSD 7.6 too. Keep things simpler and drop
the OpenBSD-specific sysctl() method.

Thanks to Christian Weisgerber.

liblzma: Tweak a comment

CMake: Bump maximum policy version to 3.30

CMake: Require CMake 3.20 or later

This allows a few cleanups.

Update THANKS

xz: Remove the TODO comment about --recursive

It won't be implemented. find + xargs is more flexible, for example,
it allows compressing small files in parallel. An example for that
has been included in the xz man page since 2010.

Document --disable-loongarch-crc32 in INSTALL

CMake: Link xz against Threads::Threads if using pthreads

The liblzma target was recently changed to link against Threads::Threads
with the PRIVATE keyword. I had forgotten that xz itself depends on
pthreads too due to pthread_sigmask(). Thus, the build broke when
building shared liblzma and pthread_sigmask() wasn't in libc.

Thanks to Peter Seiderer for the bug report.

Fixes: ac05f1b0d7cda1e7ae79775a8dfecc54601d7f1c
Fixes: https://github.com/tukaani-project/xz/issues/129#issuecomment-2204522994

Update THANKS

CMake: Improve NLS error messages

CMake: Update the comment at the top of CMakeLists.txt

While po/*.gmo files won't be used from the release tarball,
the generated translated man pages will be used still. Those
are text files and po4a has slightly more dependencies than
gettext tools so installing po4a might be a bit more challenging
in some situations.

CMake: Drop support for pre-generated po/*.gmo files

When a release tarball is created using Autotools, the tarball includes
po/*.gmo files which are binary files generated from po/*.po. Other
tarball creation methods don't and won't create the .gmo files.

It feels clearer if CMake will never install pre-generated binary files
from the source package. If people are able to install CMake, they
likely are able to install gettext tools as well (assuming they want
translations).

CMake: Make XZ_NLS handling more robust

If a user set XZ_NLS=ON but find_package(Intl) failed or CMake version
wasn't at least 3.20, the configuration would fail in a cryptic way.

If XZ_NLS is enabled, require that CMake is new enough and that either
gettext tools or pre-generated .gmo files are available. Otherwise fail
the configuration. Previously missing gettext tools and .gmo files would
only result in a warning.

Missing man page translations are still only a warning.

Thanks to Peter Seiderer for the bug report.

Fixes: https://github.com/tukaani-project/xz/issues/129
Closes: https://github.com/tukaani-project/xz/pull/130

CI: Add gettext as a dependency to CMake builds

CMake: Fix ENABLE_NLS comment too

Fixes: 29f77c7b707f2458fb047e77497354b195e05b14

CMake: The compile definition is ENABLE_NLS, not XZ_NLS

The CMake variables were renamed and accidentally also
the compile definition was renamed. As a result, translation
support wasn't actually enabled in the executables.

Fixes: 29f77c7b707f2458fb047e77497354b195e05b14

Update AUTHORS and THANKS

liblzma: Speed up CRC32 calculation on 64-bit LoongArch

The crc.w.{b/h/w/d}.w instructions in LoongArch can calculate the CRC32
result for 1/2/4/8 bytes in a single operation. Using these is much
faster compared to the generic method.

Optimized CRC32 is enabled unconditionally on 64-bit LoongArch because
the LoongArch specification says that CRC32 instructions shall be
implemented for 64-bit processors. Optimized CRC32 isn't enabled for
32-bit LoongArch processors because not enough information is available
about them.

Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>
Closes: https://github.com/tukaani-project/xz/pull/86

liblzma: ARM64 CRC32: Align the buffer faster

Instead of doing it byte by byte, use the 1/2/4-byte CRC32 instructions.

CI: Speed up Valgrind job by using --trace-children-skip-by-arg=...

This addresses the issue I mentioned in
6c095a98fbec70b790253a663173ecdb669108c4 and speeds up the Valgrind
job a bit, because non-xz tools aren't run unnecessarily with
Valgrind by the script tests.

Build: Prepend, not append, PTHREAD_CFLAGS to LIBS

It shouldn't make any difference because LIBS should be empty
at that point in configure. But prepending is the correct way
because in general the libraries being added might require other
libraries that come later on the command line.

Build: Use AC_LINK_IFELSE to handle implicit function declarations

It's more robust in case the compiler allows pre-C99 implicit function
declarations. If an x86 intrinsic is missing and gets treated as
implicit function, the linking step will very probably fail. This
isn't the only way to workaround implicit function declarations but
it might be the simplest and cleanest.

The problem hasn't been observed in the wild.

There are a couple more AC_COMPILE_IFELSE uses in configure.ac.
Of these, Landlock check calls prctl() and in theory could have
the same problem. In practice it doesn't as the check program
looks for several other things too. However, it was changed to
AC_LINK_IFELSE still to look more correct.

Similarly, m4/tuklib_cpucores.m4 and m4/tuklib_physmem.m4 were
updated although they haven't given any trouble either. They
have worked all these years because those check programs rely
on specific headers and types: if headers or types are missing,
compilation will fail. Using the linker makes these checks more
similar to the ones in cmake/tuklib_*.cmake which always link.

Build: Use AC_LINK_IFELSE instead of -Werror

AC_COMPILE_IFELSE needed -Werror because Clang <= 14 would merely
warn about the unsupported attribute and implicit function declaration.
Changing to AC_LINK_IFELSE handles the implicit declaration because
the symbol __crc32d is unlikely to exist in libc.

Note that the other part of the check is that #include <arm_acle.h>
must work. If the header is missing, most compilers give an error
and the linking step won't be attempted.

Avoiding -Werror makes the check more robust in case CFLAGS contains
warning flags that break -Werror anyway (but this isn't the only check
in configure.ac that has this problem). Using AC_LINK_IFELSE also makes
the check more similar to how it is done in CMakeLists.txt.

Build: Sync the compile check changes from CMakeLists.txt

It's nice to keep these in sync. The use of main() will later allow
AC_LINK_IFELSE usage too which may avoid the more fragile -Werror.

CMake: Not experimental anymore

While the CMake support has gotten a lot less testing than
the Autotools-based build, the supported features should now
be equal. The output may differ slightly, for example,
liblzma.pc may have

    Libs.private: -pthread -lpthread

with Autotools on GNU/Linux. CMake doesn't put any options
in Libs.private because on modern glibc the pthread functions
are in libc. The options options aren't required to link static
liblzma into an application.

Autotools-based build doesn't generate or install
lib/cmake/liblzma-*.cmake files. This means that on most
platforms one cannot rely on

    find_package(liblzma 5.2.5 REQUIRED CONFIG)

or such finding those files.

CMake: Use configure_file() to copy a file

I had missed this simpler method before. It does create a dependency
so that if .in.h changes the copying is done again.

CMake: Always add pthread flags into CMAKE_REQUIRED_LIBRARIES

It was weird to add CMAKE_THREAD_LIBS_INIT in CMAKE_REQUIRED_LIBRARIES
only if CLOCK_MONOTONIC is available. Alternative would be to remove
the thread libs from CMAKE_REQUIRED_LIBRARIES after the check for
pthread_condattr_setclock() but keeping the libs should be fine too.
Then it's ready in case more pthread functions were wanted some day.

CMake: Tweak comments

Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>

CMake: Edit white space for consistency

CMake: Fix three checks if building with -flto

In CMake, check_c_source_compiles() always links too. With
link-time optimization, unused functions may get omitted if
main() doesn't depend on them. Consider the following which
tries to check if somefunction() is available when <someheader.h>
has been included:

    #include <someheader.h>
    int foo(void) { return somefunction(); }
    int main(void) { return 0; }

LTO may omit foo() completely because the program as a whole doesn't
need it and then the program will link even if the symbol somefunction
isn't available in libc or other library being linked in, and then
the test may pass when it shouldn't.

What happens if <someheader.h> doesn't declare somefunction()?
Shouldn't the test fail in the compilation phase already? It should
but many compilers don't follow the C99 and later standards that
prohibit implicit function declarations. Instead such compilers
assume that somefunction() exists, compilation succeeds (with a
warning), and then linker with LTO omits the call to somefunction().

Change the tests so that they are part of main(). If compiler accepts
implicitly declared functions, LTO cannot omit them because it has to
assume that they might have side effects and thus linking will fail.
On the other hand, if the functions/intrinsics being used are supported,
they might get optimized away but in that case it's fine because they
really are supported.

It is fine to use __attribute__((target(...))) for main(). At least
it works with GCC 4.9 to 14.1 on x86-64.

Reported-by: Sam James <sam@gentoo.org>

CMake: Use MATCHES instead of multiple STREQUAL

CMake: Improve the comment about LIBS

CMake: Fix a typo in a message

It was spotted with codespell.

Document CMake options in INSTALL

CI: Don't omit crc32 from the list with CMake anymore

XZ_CHECKS accepts it but works without too.

CI: Workaround buggy config.guess on Ubuntu 22.04LTS and 24.04LTS

Check for the wrong triplet from config.guess and override it with
the --build option on the configure command line. Then i386 assembly
autodetection will work.

These Ubuntu versions (and as of writing, also Debian unstable)
ship config.guess version 2022-01-09 which contains a bug that
was fixed in version 2022-05-08. It results in a wrong configure
triplet when using CC="gcc -m32" to build i386 binaries.

Upstream fix:
https://git.savannah.gnu.org/cgit/config.git/commit/?id=f56a7140386d08a531bcfd444d632b28c61a6329

More information:
https://mail.gnu.org/archive/html/config-patches/2022-05/msg00003.html

CI: Use CC="gcc -m32" to get i386 compiler on x86-64

The old method put it in CFLAGS which is a wrong place because
config.guess doesn't read CFLAGS.

CI: Let CMake use the CC environment variable

CC from environment is used to initialize CMAKE_C_COMPILER so
setting CMAKE_C_COMPILER explicitly isn't needed.

The syntax in ci_build.bash was broken in case one wished to put
spaces in CC.

CMake: Add autodetection for 32-bit x86 CRC assembly usage

CMake: Move option(XZ_ASM_I386) downwards a few lines

DOS: Update Makefile and config.h for the CRC changes

liblzma: Tidy up crc_common.h

Prefix ARM64_RUNTIME_DETECTION with CRC_ and reorder it to be with
the other ARM64-specific lines. That macro isn't used outside this
file.

ARM64 CLMUL implementation doesn't exist yet and thus CRC64_ARM64_CLMUL
isn't used anywhere yet.

It's not ideal that the single-letter CRC utility macros are here
as they pollute the namespace of the LZ encoder files. Those could
be moved their own crc_macros.h like they were in 5.2.x but in practice
this is fine enough already.

liblzma: Move lzma_crcXX_table[][] declarations to crc_common.h

LZ encoder needs lzma_crc32_table[0] but otherwise those tables
are private to the CRC code. In contrast, the other things in
check.h are needed in several places.

liblzma: Make 32-bit x86 CRC assembly co-exist with CLMUL

Now runtime detection of CLMUL support can pick between the CLMUL and
the generic assembly implementations. Whatever overhead this has for
builds that omit CLMUL completely isn't important because builds for
any non-ancient system is likely to include the CLMUL code too.

Handle the CRC tables in crcXX_fast.c files because now these files
are built even when assembly code is used.

If 32-bit x86 assembly is enabled then it will always be built even
if compiler flags were such that CLMUL would be allowed unconditionally.
That is, runtime detection will be used anyway. This keeps the build
rules simpler.

In LZ encoder, build and use lzma_lz_hash_table[256] if CLMUL CRC
is used without runtime detection. Previously this wasn't needed
because crc32_table.c included the lzma_crc32_table[][] in the build
unless encoder support had been disabled. Including an 8 KiB table
was silly when only 1 KiB is actually used. So now liblzma is 7 KiB
smaller if CLMUL is enabled without runtime detection.

liblzma: CRC: Rename crcXX_generic to lzma_crcXX_generic

This prepares for the possibility that lzma_crc32_generic and
lzma_crc64_generic are extern functions.

CMake: Define HAVE_CRC_X86_ASM when 32-bit x86 CRC assembly is used

Build: Define HAVE_CRC_X86_ASM when 32-bit x86 CRC assembly is used

This makes it easier to determine when the CRC tables are needed.

CI: Update to the new renamed options in CMakeLists.txt

CMake: Add XZ_EXTERNAL_SHA256

CMake: Move threading detection a few lines up

It feels clearer this way, and when support for external SHA-256
is added, this will keep the order of the library detection the
same as in configure.ac (check for pthreads before libmd) although
it shouldn't matter in practice.

CMake: Move the sandbox code out of the liblzma section

Sandboxing is for the command line tools, not liblzma.
No functional changes.

CMake: Keep existing options in LIBS when adding -lrt

This makes no difference yet because -lrt is currently the only option
that might be added to LIBS.

CMake: Don't install scripts if the xz tool isn't built

The scripts need the xz tool.

CMake: Add XZ_TOOL_XZDEC and XZ_TOOL_LZMADEC

CMake: Add XZ_TOOL_LZMAINFO

CMake: Add XZ_TOOL_XZ

Windows: Drop Visual Studio 2013 support

This simplifies things a little. Building liblzma with VS2013 probably
still worked but building the command line tools was not supported.

Microsoft ended support for VS2013 on 2024-04.

CMake: Add XZ_TOOL_SCRIPTS

CMake: Add XZ_DOC

CMake: Refactor XZ_SYMBOL_VERSIONING to match configure.ac

Make the available options and their behavior match
--enable-symbol-versions in configure.ac.

Don't enable symbol versions on Linux if not using glibc. Previously
the generic variant was selected on Microblaze or if using NVHPC
without checking that libc is glibc.

Leave the cache variable to "auto" or "yes" if that was specified
instead of setting it to the autodetected value by default. A downside
is that one cannot easily see which variant the autodetection code
has selected. The same applies to XZ_SANDBOX and XZ_THREADS though.