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
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
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
On Tue, 8 Aug 2006 09:37:09 -0400, Kuba Ober [EMAIL PROTECTED] wrote:
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
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
Um, sorry, I didn't
I try to explain why memcpy worked before.
It did not worked. As far as I noticed, this bug does not affect small
files (=0x1000) but if file was large enough (0x1000 byte) - it will
appear.
[ . . . ]
Makes sense. Thanks for the explanation.
Cheers, Kuba
