This is disabled by default to match the default in Autotools.
Use -DUSE_DOXYGEN=ON to enable Doxygen usage.
This uses the update-doxygen script, thus this is under if(UNIX)
although Doxygen itself can run on Windows too.
(cherry picked from commit 64503cc2b76a388ced4ec5f68234a07f0dcddcd5)
This omits all comments and a few non-default options that weren't
needed. Now it contains no copyrighted content from Doxygen itself.
(cherry picked from commit 2c519f641f266fd897edf680827d9c905f411440)
The stripping method worked well with Doxygen 1.8 and 1.9 but
it doesn't work with Doxygen 1.10 anymore. Since we won't ship
pre-generated liblzma API docs anymore, the extra bloat and
extra license info of the JavaScript files won't affect the
upstream source package anymore.
(cherry picked from commit bdba39a57530d11b88440df8024002be3d09e4a1)
They will be omitted from the source tarball and I don't want
to make Doxygen a dependency of build.bash.
(cherry picked from commit 252aa1d67bc015eeba462803ab72edeb7744d864)
pdf-local rule was added to create the PDFs still with "make pdf".
The install rules are missing but that likely doesn't matter at all.
(cherry picked from commit dc684bf76ea23574ee9d88382057381e04e6089a)
This moves the tests section as is from CMakeLists.txt into
tests/tests.cmake. CMakeLists.txt now includes tests/tests.cmake
if the latter file exists.
Now it's possible to delete the whole "tests" directory and
building with CMake will still work normally, just without
the tests. This way the tests are readily available for those
who want them, and those who won't run the tests anyway have
a straightforward way to ensure that nothing from the "tests"
directory can affect the build process.
(cherry picked from commit aaff75c3486c4489ce88b0efb36b41cf138af7c3)
These are very old but the exact test file isn't easy to reproduce
as it was compiled from a short C program (bcj_test.c) long ago.
These tests weren't very good anyway, just a little better than nothing.
(cherry picked from commit a5f2aa5618fe9183706c9c514c3067985f6c338b)
On LZMA_DATA_ERROR from lzma_index_buffer_decode(), *i = NULL was
already done but this adds a test for that case too.
(cherry picked from commit 575b11b0d291e66c5fce31ce7a72f11436d57c83)
liblzma guarantees that the product of the allocation size arguments
will fit in size_t.
Putting the pre-increment in the if-statement was clearly wrong
although in practice it didn't matter here as the function is
called only a couple of times.
(cherry picked from commit 7f865577a6224fbbb5f5ca52574b62ea8ac9bf51)
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)
The __builtin_bswapXX from GCC and Clang are preferred when
they are available. This can allow compilers to emit the x86 MOVBE
instruction instead of doing a load + byteswap as two instructions
(which would happen if the byteswapping is done in inline asm).
bswap16, bswap32, and bswap64 exist in system headers on *BSDs
and Darwin. #defining bswap16 on NetBSD results in a warning about
macro redefinition. It's safest to avoid this namespace conflict
completely.
No OS supported by tuklib_integer.h uses byteswapXX names and
a web search doesn't immediately find any obvious danger of
namespace conflicts. So let's try these still-pretty-short names
for the macros.
Thanks to Sam James for pointing out the compiler warning on
NetBSD 10.0.
(cherry picked from commit 4ffc60f32397371769b7d6b5e3ed8626292d58df)
The API docs clearly say that if error_pos isn't NULL then *error
is always set on any error. However, it wasn't touched if str == NULL
or filters == NULL or unsupported flags were specified.
Fixes: cedeeca2ea6ada5b0411b2ae10d7a859e837f203
(cherry picked from commit 70d12dd069bb9bb0d6bb1c8fafc4e6f77780263d)
The array could become empty and then the initializer would be
simply {} which is allowed only in GNU-C and C23.
(cherry picked from commit b101e1d1dbc81577c0c9aa0cb89cf2e46a15eb82)
It is logical why it cannot know for sure that the value has
to be at most 4 if it is less than 16.
The x86 filter is based on a very old LZMA SDK version. Newer
ones have quite a different implementation for the same filter.
Thanks to Sam James.
(cherry picked from commit 6aa2a6deeba04808a0fe4461396e7fb70277f3d4)
