> 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
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
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 m
> > > 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.
> W
> 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 th
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
