emo/busybox
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

unlzma: expand comments, no code changes

Browse Source 
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This commit is contained in:
Denys Vlasenko 2017-01-09 14:28:25 +01:00
parent 3989e5adf4
commit 590402bb55
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
archival/libarchive/decompress_unlzma.c
View File

@ -432,6 +432,21 @@ unpack_lzma_stream(transformer_state_t *xstate)
} }
len += LZMA_MATCH_MIN_LEN; len += LZMA_MATCH_MIN_LEN;
/*
* LZMA SDK has this optimized:
* it precalculates size and copies many bytes
* in a loop with simpler checks, a-la:
* do
* *(dest) = *(dest + ofs);
* while (++dest != lim);
* and
* do {
* buffer[buffer_pos++] = buffer[pos];
* if (++pos == header.dict_size)
* pos = 0;
* } while (--cur_len != 0);
* Our code is slower (more checks per byte copy):
*/
IF_NOT_FEATURE_LZMA_FAST(string:) IF_NOT_FEATURE_LZMA_FAST(string:)
do { do {
uint32_t pos = buffer_pos - rep0; uint32_t pos = buffer_pos - rep0;
@ -451,6 +466,9 @@ unpack_lzma_stream(transformer_state_t *xstate)
} while (len != 0 && buffer_pos < header.dst_size); } while (len != 0 && buffer_pos < header.dst_size);
/* FIXME: ...........^^^^^ /* FIXME: ...........^^^^^
* shouldn't it be "global_pos + buffer_pos < header.dst_size"? * shouldn't it be "global_pos + buffer_pos < header.dst_size"?
* It probably should, but it is a "do we accidentally
* unpack more bytes than expected?" check - which
* never happens for well-formed compression data...
*/ */
} }
} }