aboutsummaryrefslogtreecommitdiff
path: root/archival/libarchive/decompress_unlzma.c
AgeCommit message (Collapse)Author
2019-07-02libbb: reduce the overhead of single parameter bb_error_msg() callsJames Byrne
Back in 2007, commit 0c97c9d43707 ("'simple' error message functions by Loic Grenie") introduced bb_simple_perror_msg() to allow for a lower overhead call to bb_perror_msg() when only a string was being printed with no parameters. This saves space for some CPU architectures because it avoids the overhead of a call to a variadic function. However there has never been a simple version of bb_error_msg(), and since 2007 many new calls to bb_perror_msg() have been added that only take a single parameter and so could have been using bb_simple_perror_message(). This changeset introduces 'simple' versions of bb_info_msg(), bb_error_msg(), bb_error_msg_and_die(), bb_herror_msg() and bb_herror_msg_and_die(), and replaces all calls that only take a single parameter, or use something like ("%s", arg), with calls to the corresponding 'simple' version. Since it is likely that single parameter calls to the variadic functions may be accidentally reintroduced in the future a new debugging config option WARN_SIMPLE_MSG has been introduced. This uses some macro magic which will cause any such calls to generate a warning, but this is turned off by default to avoid use of the unpleasant macros in normal circumstances. This is a large changeset due to the number of calls that have been replaced. The only files that contain changes other than simple substitution of function calls are libbb.h, libbb/herror_msg.c, libbb/verror_msg.c and libbb/xfuncs_printf.c. In miscutils/devfsd.c, networking/udhcp/common.h and util-linux/mdev.c additonal macros have been added for logging so that single parameter and multiple parameter logging variants exist. The amount of space saved varies considerably by architecture, and was found to be as follows (for 'defconfig' using GCC 7.4): Arm: -92 bytes MIPS: -52 bytes PPC: -1836 bytes x86_64: -938 bytes Note that for the MIPS architecture only an exception had to be made disabling the 'simple' calls for 'udhcp' (in networking/udhcp/common.h) because it made these files larger on MIPS. Signed-off-by: James Byrne <james.byrne@origamienergy.com> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2018-11-27unlzma: fix too-eager corruption checkDenys Vlasenko
function old new delta unpack_lzma_stream 2686 2674 -12 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2018-05-25unlzma: close another SEGV possibilityDenys Vlasenko
function old new delta unpack_lzma_stream 2669 2686 +17 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2018-04-24unlzma: do emit the error message on bad input, when we exit with 1Denys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2018-04-19unlzma: fix another SEGV caseDenys Vlasenko
function old new delta unpack_lzma_stream 1705 1717 +12 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2018-04-08unlzma: fix segfault on bad archiveDenys Vlasenko
function old new delta unpack_lzma_stream 2647 2653 +6 Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2017-10-27unlzma: fix SEGV, closes 10436Denys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2017-01-09unlzma: expand comments, no code changesDenys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2017-01-09unlzma: fix erroneous "while" instead of "if". Closes 4682Denys Vlasenko
These parts of the code essentially check whether stepping back by rep0 goes negative or not. LZMA SDK from lzma1604.7z has the following in the corresponding places: ... = dic[dicPos - rep0 + (dicPos < rep0 ? dicBufSize : 0)] Clearly, not loop here. Technically, "while" here works: if condition is false (because pos underflowed), it iterates once, adds header.dict_size (a.k.a. dicBufSize), this makes pos positive but smaller than header.dict_size, and loop exits. Now we'll just check for negative result of subtraction, which is less code: function old new delta unpack_lzma_stream 2659 2641 -18 (I hope 2 Gbyte+ dictionaries won't be in use soon). Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2014-12-07libarchive: add capability to unpack to mem.bufferDenys Vlasenko
The performance and number of processes for a "depmod -a" with gzipped modules was abysmal. This patch adds a code path without fork, benefiting all users of xmalloc_open_zipped_read_close. "modinfo radeon.ko.gz", a single-file reader, got 30% faster. "depmod -a", which used to fork over 800 times, got 20% faster. Heavily based on a patch by Lauri Kasanen <curaga@operamail.com> function old new delta setup_transformer_on_fd - 159 +159 transformer_write - 122 +122 fork_transformer - 112 +112 xmalloc_open_zipped_read_close 63 118 +55 read_bunzip 1866 1896 +30 xtransformer_write - 19 +19 unzip_main 2449 2462 +13 bbunpack 755 766 +11 unpack_lzma_stream 2717 2723 +6 unpack_xz_stream 2393 2397 +4 unpack_Z_stream 1173 1175 +2 inflate_unzip 111 105 -6 check_signature16 70 63 -7 unpack_bz2_stream 359 349 -10 unpack_unxz 12 - -12 unpack_unlzma 12 - -12 unpack_uncompress 12 - -12 unpack_gunzip 12 - -12 unpack_bunzip2 12 - -12 open_transformer 106 92 -14 inflate_unzip_internal 1945 1916 -29 unpack_gz_stream 693 655 -38 open_zipped 89 47 -42 setup_unzip_on_fd 142 53 -89 ------------------------------------------------------------------------------ (add/remove: 4/5 grow/shrink: 7/8 up/down: 533/-295) Total: 238 bytes Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2014-12-07Rename transformer_aux_data_t -> transformer_state_tDenys Vlasenko
No code changes Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2014-02-28unlzma: add comments about possible bug from BZ 2689Denys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2014-02-28unlzma: move some variables in "more local" scopeDenys Vlasenko
No code changes as verified by objdump Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2013-03-01decompress_unlzma: move function, no code changesDenys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2013-03-01decompress_unlzma: 10% speedup in "small" codeDenys Vlasenko
text data bss dec hex filename 1796 0 0 1796 704 decompress_unlzma.o 1801 0 0 1801 709 decompress_unlzma.o Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2013-03-01decompress_unlzma: make "fast" version a bit smallerDenys Vlasenko
It is not slower. In fact it seems a tiny bit faster too. text data bss dec hex filename 2827 0 0 2827 b0b decompress_unlzma.o 2797 0 0 2797 aed decompress_unlzma.o Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2012-03-06update seamless uncompression codeDenys Vlasenko
This change makes "tar tf hello_world.txz" work without adding special-casing for ".txz" extension. It also removes ever-growing magic checking code in rpm2cpio and get_header_tar - we reuse one which lives in setup_unzip_on_fd. function old new delta unpack_gz_stream 7 566 +559 check_signature16 - 70 +70 setup_unzip_on_fd 99 142 +43 handle_SIGCHLD - 41 +41 unpack_bz2_stream 342 376 +34 unzip_main 2352 2385 +33 bbunpack 503 533 +30 open_transformer 74 102 +28 unpack_Z_stream 1278 1304 +26 unpack_gunzip 101 123 +22 init_transformer_aux_data - 18 +18 unpack_xz_stream 2388 2402 +14 open_zipped 131 141 +10 rpm_main 1358 1363 +5 get_header_tar_lzma 52 57 +5 get_header_tar_bz2 52 57 +5 unpack_lzma_stream 2698 2702 +4 hash_find 234 233 -1 get_header_tar 1759 1733 -26 get_header_tar_gz 92 57 -35 unpack_uncompress 51 12 -39 rpm2cpio_main 201 147 -54 unpack_unxz 67 12 -55 unpack_bz2_stream_prime 55 - -55 get_header_tar_Z 86 - -86 unpack_gz_stream_with_info 539 - -539 ------------------------------------------------------------------------------ (add/remove: 3/3 grow/shrink: 14/6 up/down: 947/-890) Total: 57 bytes Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2011-09-22rename archive.h to bb_archive.h. no code changesDenys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
2010-11-03rename archival/libunarchive -> archival/libarchive; move bz/ into itDenys Vlasenko
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>