HolyLich wrote:
ChangeLog: Fix rather unusual bug in LZ77 decompressor. We cannot use
memcpy
with overlapped areas because of unpredictable result. We must
copy
byte-by-byte.Why don't you use memmove instead? The man page for memcpy says: Use memmove(3) if the memory areas do overlap.
We cannot use memmove. It provides different functionality. It moves blocks, but LZ77 decompress algorithm copies bytes.
Let's suppose: 012 XYZ
When we say 'memmove(1, 0, 2)' we will get: 012 XXY
But we (LZ77 algorithm) expect: 012 XXX (three 'X').
memcpy is rather clever (it optmizes process by coping INT instead of BYTES). This optimization is fatal for LZ77.
For more information, please, refer to patch. It contains some useful comment.
--HolyLich
Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy with overlapped areas because of unpredictable result. We must copy byte-by-byte.
Why don't you use memmove instead? The man page for memcpy says: Use memmove(3) if the memory areas do overlap.
We cannot use memmove. It provides different functionality. It moves blocks, but LZ77 decompress algorithm copies bytes.
Let's suppose: 012 XYZ
When we say 'memmove(1, 0, 2)' we will get: 012 XXY
But we (LZ77 algorithm) expect: 012 XXX (three 'X').
memcpy is rather clever (it optmizes process by coping INT instead of BYTES). This optimization is fatal for LZ77.
Why?
Er, if the memcpy worked (or almost worked) and failed due to overlap problems, then memmove will do the trick. Did it ever work at all before? Either this code never worked, or you're either seeing a problem that doesn't exist/misunderstanding things.
Cheers, Kuba
-
HolyLich -
Kuba Ober