This requires a filename (or something that pretends to be a filename)
of at least 2 GiB on a 32-bit platform, and that realloc() to
SIZE_MAX / 2 + 1 bytes has succeeded.
Fixes: https://github.com/tukaani-project/xz/pull/218
The __builtin_assume_aligned was applied to the wrong argument which
made aligned writes worse on strict-align archs.
Aligned writes aren't used in liblzma, so this bug didn't matter in
this package; tuklib_integer.h is meant to be usable elsewhere too.
It makes clang -std=gnu23 noisy about bool. It's also noisy about
[[__fallthrough__]] which is only used in C23 mode.
Reported-by: Collin Funk <collin.funk1@gmail.com>
On QNX calling fsync on a directory fails with EINVAL. This causes the
following test failure:
$ cat tests/test_suffix.sh.log
/data/home/root/xz-5.8.2/src/xz/.libs/lt-xz: suffix_temp: Synchronizing the directory of the file failed: Invalid argument
Failed to decompress a file with a suffix set in raw format
FAIL test_suffix.sh (exit status: 1)
Closes: https://github.com/tukaani-project/xz/pull/216
__cpuid from MSVC (and also the old Intel ICC) use int[], while
__get_cpuid from <cpuid.h> in GCC and Clang use unsigned int[].
Adding a cast is the simplest fix.
Link: https://github.com/tukaani-project/xz/pull/208
The configure_file() calls for xzdiff, xzgrep, xzmore, and xzless
were running unconditionally within the if(UNIX) block, even when
ENABLE_SCRIPTS was OFF. This would cause a build failure if the
src/scripts/*.in files were not present. Deleting those files can
simplify license compliance when the scripts aren't needed.
Move the foreach loop and related code inside if(ENABLE_SCRIPTS) guard
so that configure_file() is only called when scripts are actually needed.
This is mostly whitespace changes to adjust the indentation.
Co-authored-by: Lasse Collin <lasse.collin@tukaani.org>
Closes: https://github.com/tukaani-project/xz/pull/210
The "License" property is a pkgconf extension. See pc(5).
pkg-config 0.29.2 (2017) ignores unrecognized properties so this
commit shouldn't create compatibility issues.
pkgconf provides bomtool which uses the "License" property to generate
a software bill of materials. In pkgconf.git there is spdxtool for the
same task but with different output format.
The pkgconf extensions "Copyright" and "Maintainer" would also be
used by bomtool and spdxtool, but I don't want to add those properties
at least for now.
Co-authored-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Closes: https://github.com/tukaani-project/xz/pull/178
If the cache variable TUKLIB_FAST_UNALIGNED_ACCESS is already set,
the autodetection result isn't needed because the option() command
does nothing when the cache variable is already set.
This is largely white space change to indent the if...endif block.
CMake >= 4.1 sets CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID on many
platforms. The list of possible values are documented. Use this
variable when available. On older CMake versions CMAKE_SYSTEM_PROCESSOR
is still used, thus the regexes have to include values like ^amd64 still.
With old CMake versions, checking CMAKE_C_COMPILER_ARCHITECTURE_ID
is somewhat useful with MSVC because CMAKE_SYSTEM_PROCESSOR might
not match the target architecture.
On ARM64, support for fast unaligned memory access was autodetected by
checking if __ARM_FEATURE_UNALIGNED is defined. However, at least GCC
versions up to 15.2.0 define the macro even when -mstrict-align has
been specified. Thus, autodetection with GCC doesn't work correctly,
and binaries built using -mstrict-align can be much slower than they
need to be, unless the user also passes --disable-unaligned-access
to configure or -DTUKLIB_FAST_UNALIGNED_ACCESS=OFF to cmake.
See the GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555
Workaround the issue by using heuristics with GCC on ARM64.
With Clang, the detection using __ARM_FEATURE_UNALIGNED works.
It also works with GCC on 32-bit ARM.
Fixes: e5f13a66567b ("tuklib_integer: Autodetect support for unaligned access on ARM.")
There are no strings to translate in that file now, but it's good to
list it anyway in case translatable strings are added in the future.
Fixes: 374868d81d47 ("xz: Move sandboxing code to sandbox.c and improve Landlock sandbox.")
This was already the case in practice because I had forgotten to list
src/xz/sandbox.c in po/POTFILES.in. However, it seems better to never
translate this particular error message. It should almost never occur
and if it does, an untranslated message is should make it easier to
find bug reports about it.
This still relies on CMAKE_SYSTEM_PROCESSOR. CMake 4.1 added more
CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID values to detect the arch in
a more defined manner, but 4.1 is too new to require for now.
Thanks-to: Li Chenggang <lichenggang@deepin.org>
Closes: https://github.com/tukaani-project/xz/pull/186
According to [1] sections 7.4, 8.1, and 8.2, desktop and server
processors support fast unaligned access, but embedded systems likely
don't.
It's important that TUKLIB_FAST_UNALIGNED_ACCESS isn't defined when
-mstrict-align is in use because it will result in slower binaries
even if running on a processor that supports fast unaligned access.
It's because compilers will translate multibyte memcpy() to multiple
byte-by-byte instructions instead of wider loads and stores. The
compression times from [2] show this well:
Unaligned access CFLAGS Compression time
enabled -O2 -mno-strict-align 66.1 s
disabled -O2 -mno-strict-align 79.5 s
disabled -O2 -mstrict-align 79.9 s
enabled -O2 -mstrict-align 129.1 s
There currently (GCC 15.2) is no preprocessor macro on LoongArch
to detect if -mstrict-align or -mno-strict-align is in effect (the
default is -mno-strict-align). Use heuristics to detect which of the
flags is in effect.
[1] https://github.com/loongson/la-softdev-convention/blob/v0.2/la-softdev-convention.adoc
[2] https://github.com/tukaani-project/xz/pull/186#issuecomment-3494570304
Thanks-to: Li Chenggang <lichenggang@deepin.org>
Thanks-to: Xi Ruoyao
See: https://github.com/tukaani-project/xz/pull/186
