Reduce L1,L2 cache miss in the rar reader.
A use of large memory(over 1M bytes) for an output buffer makes
a lot of cache misses, so we should eliminate it as possible as we can.
Reduce the sum of a calling of write system-call in extracting RAR file.
For example, extracting test_read_format_rar_ppmd_lzss_conversion.rar.uu:
The sum came down from 62947 to 60.
Improve lzss_emit_match() to be faster than previous version.
This cahnge makes user CPU time less about 40% when extracting
test_read_format_rar_ppmd_lzss_conversion.rar.uu.
This idea from our lha reader.
Andres Mejia [Tue, 9 Aug 2011 03:27:24 +0000 (23:27 -0400)]
Modify ppmd7 code to minimize symbols leaked into the global name space.
Only one extra symbol is add, __archive_ppmd7_functions, which is a global
struct carrying function pointers to ppmd7 functions.
Properly check a header CRC to avoid reading a broken header and extracting
file data based on its unreliable parameters such as a compressed size or
an uncompressed size.
Tim Kientzle [Sun, 7 Aug 2011 17:34:20 +0000 (13:34 -0400)]
Partial merge of r2431 from trunk: Retry writes on EINTR.
This should fix the SIGINT handler in bsdtar.
Note: The rest of r2431 can't be merged, since it interacts
with a big write-side rearchitecture.
Effectively read compressed data into a cache buffer of bit readers
without bytes-swap functions. A use of our byte-swap functions needed
extra bit shifts at bit readers.
Andres Mejia [Sat, 6 Aug 2011 21:54:00 +0000 (17:54 -0400)]
Implement support for RAR files compressed using "best" and "good" method.
PPMd code used is public domain code from p7zip. It seems 7z and RAR "good" and
"best" compressed files had a lot in common. Very little changes were needed
from original code so that it would work with RAR files and work with
libarchive. Currently, this will not work correctly with largefiles compressed
using PPMd.
Back to simply invoke lha_crc16(). Crrently the total cost of the
calculation of CRC16 is almost the same as previous complex code,
so it is better that we make that code simple.
It would be better to return ARCHIVE_FAILED instead of ARCHIVE_FATAL
when there is something wrong in extracting RAR files, because
you may extract the next entry file in the RAR archive file.
Stop extracting a RAR file if making huffman table fails, and report it in order to avoid an infinity loop
at reading damaged RAR files, which is made by test_fuzz.
When Skipping data in a store mode, use rar->bytes_remaining instead of rar->packed_size.
a use of packed_size in that case will not work after archive_read_format_rar_read_data
has been called.
Check the return value of __archive_read_consume in decoding lzss to avoid infinity loop in test_fuzz
because rar->bitoffset can have untrusted value when reading damaged RAR files.
Colin Percival [Tue, 2 Aug 2011 12:20:40 +0000 (08:20 -0400)]
Fix printing of INT(MAX|64)_MIN. In append_int we had theoretically
undefined behaviour, but the code probably worked on all existing
compilers and platforms. In format_int we could get the wrong output,
but only on files created/modified 280 billion years before the Big
Bang.
Colin Percival [Tue, 2 Aug 2011 08:56:27 +0000 (04:56 -0400)]
Make sure that the argument to --strip-components is a number. Otherwise
if someone accidentally omits the argument, we'll silently eat the next
command line argument. (GNU tar checks this, otherwise I wouldn't bother.)
Reduce a use of memory for decoding huffman code in both lha and cab reader.
Its side effect significantly reduces L1 cache miss observed with cachegrind,
which is one of valgrind tools.
Colin Percival [Mon, 1 Aug 2011 16:13:32 +0000 (12:13 -0400)]
Fix mtree_atol16. There was a missing ++(*p), with the result that the
values "0x[1-9].*" would be mapped to INT64_MAX, "0x-[1-9].*" would be
mapped to -INT64_MAX (which is another bug; it should have been INT64_MIN),
and "0x0.*" and "0x-0.*" would result in an infinite loop.
As part of this fix, factor out the duplicated digit-or-alpha-or-ALPHA
parsing into a separate function; I'm sure this complexity was responsible
for the increment getting lost in the first place.
Colin Percival [Mon, 1 Aug 2011 07:41:48 +0000 (03:41 -0400)]
Fix overflow handling in mtree_atol10. Prior to this commit, the value
"-9223372036854775808" (aka. -2^63 aka. INT64_MIN) will be parsed and
returned as -9223372036854775807 (aka. -INT64_MAX).
Tim Kientzle [Tue, 19 Jul 2011 05:02:05 +0000 (01:02 -0400)]
When scanning the beginning of an ASCII text file to see if it
has a uuencode 'begin' sequence, only examine the first 128k.
Extend the test to verify that we don't recognize uuencoded
data with 512k of leading ASCII data.
In iso9660 writer and xar writer, always overwrite the existing file in the file tree
which file has the same name; it is better that front-end applications such as tar decide
how they handle that case.
projects / thirdparty / libarchive.git / log
