From 590402bb55be940310f68d14a540f2d109420a98 Mon Sep 17 00:00:00 2001 From: Denys Vlasenko Date: Mon, 9 Jan 2017 14:28:25 +0100 Subject: [PATCH] unlzma: expand comments, no code changes Signed-off-by: Denys Vlasenko --- archival/libarchive/decompress_unlzma.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/archival/libarchive/decompress_unlzma.c b/archival/libarchive/decompress_unlzma.c index 90a428583..a9040877e 100644 --- a/archival/libarchive/decompress_unlzma.c +++ b/archival/libarchive/decompress_unlzma.c @@ -432,6 +432,21 @@ unpack_lzma_stream(transformer_state_t *xstate) } 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:) do { 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); /* FIXME: ...........^^^^^ * 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... */ } } -- 2.25.1