Merging upstream version 0.8.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 10 insertions, 11 deletions

diff --git a/README b/README
index 7395a92..00c45ee 100644
--- a/README
+++ b/README
@@ -4,7 +4,7 @@ Xlunzip is a test tool for the lzip decompression code of my lzip patch for
 linux. Xlunzip is similar to lunzip, but it uses the lzip_decompress linux
 module as a backend. Xlunzip tests the module for stream, buffer-to-buffer,
 and mixed decompression modes, including in-place decompression (using the
-same buffer for input and output). You can use xlunzip to verify that the
+same buffer for input and output). You can use xlunzip to check that the
 module produces correct results when decompressing single member files,
 multimember files, or the concatenation of two or more compressed files.
 Xlunzip can be used with unzcrash to test the robustness of the module to
@@ -26,7 +26,7 @@ Lzip related components in the kernel
 =====================================
 
 The lzip_decompress module in lib/lzip_decompress.c provides a versatile
-lzip decompression function able to do buffer to buffer decompression or
+lzip decompression function able to do buffer-to-buffer decompression or
 stream decompression with fill and flush callback functions. The usage of
 the function is documented in include/linux/lzip.h.
 
@@ -76,7 +76,7 @@ address |    *   ,'
 
 All we need to know to calculate the minimum required extra space is:
   The maximum expansion ratio.
-  The size of the last part of a member required to verify integrity.
+  The size of the last part of a member required to check integrity.
   For multimember data, the overhead per member. (36 bytes for lzip).
 
 The maximum expansion ratio of LZMA data is of about 1.4%. Rounding this up
@@ -87,22 +87,21 @@ required to decompress lzip data in place is:
 
 Using the compressed size to calculate the extra_bytes (as in the formula
 above) may slightly overestimate the amount of space required in the worst
-case. But calculating the extra_bytes from the uncompressed size (as does
-linux currently) is wrong (and inefficient for high compression ratios). The
-formula used in arch/x86/boot/header.S
+case (maximum expansion). But calculating the extra_bytes from the
+uncompressed size (as does linux currently) is wrong (and inefficient for
+high compression ratios). The formula used in arch/x86/boot/header.S:
 
-  extra_bytes = ( uncompressed_size >> 8 ) + 65536
+  extra_bytes = ( uncompressed_size >> 8 ) + 131072
 
 fails to decompress 1 MB of zeros followed by 8 MB of random data, wastes
 memory for compression ratios larger than 4:1, and does not even consider
 multimember data.
 
 
-Copyright (C) 2016-2021 Antonio Diaz Diaz.
+Copyright (C) 2016-2024 Antonio Diaz Diaz.
 
 This file is free documentation: you have unlimited permission to copy,
 distribute, and modify it.
 
-The file Makefile.in is a data file used by configure to produce the
-Makefile. It has the same copyright owner and permissions that configure
-itself.
+The file Makefile.in is a data file used by configure to produce the Makefile.
+It has the same copyright owner and permissions that configure itself.