LZMS: Do not do x86 translations starting in last 16 bytes
authorEric Biggers <ebiggers3@gmail.com>
Sun, 12 Jan 2014 22:49:09 +0000 (16:49 -0600)
committerEric Biggers <ebiggers3@gmail.com>
Sun, 12 Jan 2014 22:59:02 +0000 (16:59 -0600)
The value used before (last 11 bytes) was wrong; based on tests with the
MS implementation no translation can occur following an opcode starting
in the last 16 bytes of a data block.

Tested with two different length opcodes to make sure that it's the start
of the opcode that matters, not the start of the translated address.

NEWS
src/lzms-common.c

diff --git a/NEWS b/NEWS
index 3c4d23f..033d704 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,13 @@ Version 1.6.1:
        Stored files with size exactly 4 GiB (4,294,967,296 bytes) are now
        decompressed correctly.
 
+       Fixed a minor compatibility issue with the LZMS compressor and
+       decompressor.  This is *not* the default compression type and was only
+       introduced in v1.6.0.  In the unlikely event that you created a
+       LZMS-compressed WIM with v1.6.0 and a checksum error is reported when
+       applying it with v1.6.1, decompress it with v1.6.0 then compress it with
+       v1.6.1.
+
        Paths passed to wimlib_extract_paths() and wimlib_iterate_dir_tree() may
        now use either forwards or backwards slashes, as documented.
 
index 92f28c2..a34fb24 100644 (file)
@@ -293,7 +293,7 @@ lzms_x86_filter(u8 data[restrict],
        for (s32 i = 0; i < 65536; i++)
                last_target_usages[i] = -LZMS_X86_MAX_GOOD_TARGET_OFFSET - 1;
 
-       for (s32 i = 0; i < size - 11; ) {
+       for (s32 i = 0; i < size - 16; ) {
                s32 max_trans_offset;
                s32 n;