liblzma: Silence warnings from "clang -Wimplicit-fallthrough"

Build: Use -Wimplicit-fallthrough=5 when supported

Now that we have the FALLTHROUGH macro, use the strictest mode with
GCC so that comment-based fallthrough markings are no longer accepted.

In GCC, -Wextra includes -Wimplicit-fallthrough=3 and
-Wimplicit-fallthrough is the same as -Wimplicit-fallthrough=3.
Thus, the strict mode requires specifying -Wimplicit-fallthrough=5.

Clang has -Wimplicit-fallthrough which is *not* enabled by -Wextra.
Clang doesn't have a variant that takes an argument. Thus we need
to check for -Wimplicit-fallthrough. Do it before checking for
-Wimplicit-fallthrough=5 so that the latter overrides the former
when using GCC.

Replace "Fall through" comments with FALLTHROUGH

sysdefs.h: Add FALLTHROUGH macro

xzdec: Fix language in a comment

Windows: Make NLS require UCRT and gettext-runtime >= 0.23.1

Also remove the recently-added workaround from tuklib_gettext.h.
Requiring a new enough gettext-runtime is cleaner. I guess it's
mostly MSYS2 where xz is built with translation support, so once
MSYS2 has Gettext >= 0.23.1, this requirement shouldn't be a problem
in practice.

windows/build-with-cmake.bat: Fix ENABLE_NLS to XZ_NLS

Fixes: 29f77c7b707f2458fb047e77497354b195e05b14

Build: Use git log --pretty=medium when creating ChangeLog

It's the default in git-log. Specifying it explicitly is good in case
a user has set format.pretty to a different value.

Windows: Update MinGW-w64 + CMake instructions to recommend UCRT

xz man page: Describe the source file deletion in -z and -d options

The DESCRIPTION section always explained it, and the OPTIONS section
only described the differences to the default behavior. However, new
users in a hurry may skip reading DESCRIPTION. The default behavior
is a bit dangerous, thus it's good to repeat in --compress and
--decompress docs that source file is removed after successful operation.

Fixes: https://github.com/tukaani-project/xz/issues/150

Build: Set libtool -version-info so that it matches with CMake

In the past, they haven't been in sync in development versions
although they (of course) have been in stable releases.

CMake/macOS: Use GNU Libtool compatible shared library versioning

Because this increases the Mach-O compatibility_version, this commit
shouldn't cause any ABI compatibility trouble for existing CMake users
on macOS. This is assuming that they won't later downgrade to an older
liblzma version that was built with CMake before this commit.

Meson allows customising the Mach-O versioning too. So the three
build systems can be configured to be compatible.

CMake: Edit a comment

version.sh: Omit an unwanted dot from development versions

It printed 5.7.0.alpha instead of 5.7.0alpha.

Fixes: e7a42cda7c827e016619e8cab15e2faf5d4181ae

CMake: Remove a duplicate word from a comment

INSTALL: Document CMAKE_DLL_NAME_WITH_SOVERSION

xz: Fix comments

CMake: Disable unity builds project-wide

liblzma and xz can't be compiled as a unity/jumbo build because of
redeclarations and type name reuse. The CMake documentation recommends
setting UNITY_BUILD to false in this case.

This is especially important if we're compiled as a subproject and the
consumer wants to use CMAKE_UNITY_BUILD=ON for the rest of their code
base.

Closes: https://github.com/tukaani-project/xz/pull/158

Windows: Workaround a UTF-8 issue in Gettext's libintl_setlocale()

See the comment. In this package, locale is set at program startup and
not changed later, so the point (2) in the comment isn't a problem.

Fixes: 46ee0061629fb075d61d83839e14dd193337af59

Revert "Windows: Use UTF-8 locale when active code page is UTF-8"

This reverts commit 0d0b574cc45045d6150d397776340c068df59e2a.

xzdec: Use setlocale() instead of tuklib_gettext_setlocale()

xzdec isn't translated and doesn't need libintl on Windows even
when NLS is enabled, thus libintl_setlocale() cannot interfere
with the locale settings. Thus, standard setlocale() works perfectly.

In the commit 78868b6e, the explanation in the commit message is wrong.

Fixes: 78868b6ed63fa4c89f73e3dfed27abfb8b0d46db

Windows: Revert the setlocale(LC_ALL, ".UTF8") documentation

Only leave the FindFileFirstA() notes from 20dfca81, reverting
the incorrect setlocale() notes. On Windows, Gettext's <libintl.h>
overrides setlocale() with libintl_setlocale() wrapper. I hadn't
noticed this, and thus my conclusions were wrong.

Fixes: 20dfca8171dad4c64785ac61d5b68972c444877b

tuklib_mbstr_wrap: Silence a warning from Clang

Fixes: ca529c3f41a4a19a59e2e252e6dd9255f130c634

Update THANKS

Update TODO

Fixes: 5f6dddc6c911df02ba660564e78e6de80947c947

lzmainfo: Use tuklib_mbstr_nonprint

xzdec: Use tuklib_mbstr_nonprint

xz: Use tuklib_mbstr_nonprint

Call tuklib_mask_nonprint() on filenames and also on a few other
strings from the command line too.

The filename printed by "xz --robot --list" (in list.c) is also masked.
It's good to get rid of tabs and newlines which would desync the output
but masking other chars wouldn't be strictly necessary. It might matter
with sensible filenames if LC_CTYPE is "C" (when iswprint() might reject
non-ASCII chars) and a script wants to read a filename from xz's output.
Hopefully it's an unusual enough corner case to not be a real problem.

Add tuklib_mbstr_nonprint to mask non-printable characters

Malicious filenames or other untrusted strings may affect the state of
the terminal when such strings are printed as part of (error) messages.
Add functions that mask such characters.

It's not enough to handle only single-byte control characters.
In multibyte locales, some control characters are multibyte too, for
example, terminals interpret C1 control characters (U+0080 to U+009F)
that are two bytes as UTF-8.

Instead of checking for control characters with iswcntrl(), this
uses iswprint() to detect printable characters. This is much stricter.
On Windows it's actually too strict as it rejects some characters that
definitely are printable.

Gnulib's quotearg would do a lot more but I hope this simpler method
is good enough here.

Thanks to Ryan Colyer for the discussion about the problems of
the earlier single-byte-only method.

Thanks to Christian Weisgerber for reporting a bug in an earlier
version of this code.

Thanks to Jeroen Roovers for a typo fix.

Closes: https://github.com/tukaani-project/xz/pull/118

Translations: Add preliminary Georgian translation

Most of the auto-wrapped strings are translated already. A few
strings have changed since this was created though. This file
isn't in the Translation Project *yet* because these strings
are still very new.

Closes: https://github.com/tukaani-project/xz/pull/145

xz: Make one string simpler for translators

Leading spaces in the string can get miscounted by translators.

lzmainfo: Sync the translatable strings with xz

xz: Use automatic word wrapping for help texts

--long-help is now one line longer because --lzma1 is now on its
own line.

po/Makevars: Add --keyword=W_:... to XGETTEXT_OPTIONS

The text was copied from tuklib_gettext.h.

Also rearrange the --keyword options to be last on the line.

Add tuklib_mbstr_wrap for automatic word wrapping

Automatic word wrapping makes translators' work easier and reduces
errors like misaligned columns or overlong lines. Right-to-left
languages and languages that don't use spaces between words will
still need extra effort. (xz hasn't been translated to any RTL
language so far.)

Build: Sort filenames to ASCII order in Makefile.am

tuklib_mbstr_width: Add tuklib_mbstr_width_mem()

It's a new function split from tuklib_mbstr_width().
It's useful with partial strings that aren't terminated with \0.

tuklib_mbstr_width: Update a comment about shift states

tuklib_mbstr_width: Don't mention shift states in the API docs

It is assumed that this code won't be used with charsets that use
locking shift states.

tuklib_mbstr_width: Use stricter return value checking

This should make no difference in practice (at least if mbrtowc()
isn't broken).

tuklib_mbstr_width: Change the behavior when wcwidth() is not available

If wcwidth() isn't available (Windows), previously it was assumed
that one byte == one column in the terminal. Now it is assumed that
one multibyte character == one column. This works better with UTF-8.
Languages that only use single-width characters without any combining
characters should work correctly with this.

In xz, none of po/*.po contain combining characters and only ko.po,
zh_CN.po, and zh_TW.po contain fullwidth characters. Thus, "only"
those three translations in xz are broken on Windows with the
UTF-8 code page. Broken means that column headings in xz -lvv and
(only in the master branch) strings in --long-help are misaligned,
so it's not a huge problem. I don't know if those three languages
displayed perfectly before the UTF-8 change because I hadn't tested
translations with native Windows builds before.

Fixes: 46ee0061629fb075d61d83839e14dd193337af59

xzdec: Use setlocale() via tuklib_gettext_setlocale()

xzdec isn't translated and didn't have locale-specific behavior
in the past. On Windows with UTF-8 in the application manifest,
setting the locale makes a difference though:

  - Without any setlocale() call, non-ASCII filenames don't display
    properly in Command Prompt unless one first uses "chcp 65001"
    to set the console code page to UTF-8.

  - setlocale(LC_ALL, "") is enough to make non-ASCII filenames
    print correctly in Command Prompt without using "chcp 65001",
    assuming that the non-UTF-8 code page (like 850) supports
    those non-ASCII characters.

  - setlocale(LC_ALL, ".UTF8") is even better because then mbrtowc() and
    such functions use an UTF-8 locale instead of a legacy code page.
    The tuklib_gettext_setlocale() macro takes care of this (without
    enabling any translations).

Fixes: 46ee0061629fb075d61d83839e14dd193337af59

Windows: Use UTF-8 locale when active code page is UTF-8

XZ Utils 5.6.3 set the active code page to UTF-8 to fix CVE-2024-47611.
This wasn't paired with UCRT-specific setlocale(LC_ALL, ".UTF8"), thus
non-ASCII characters from translations became mojibake.

Fixes: 46ee0061629fb075d61d83839e14dd193337af59

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