Closed vt-alt closed 3 months ago
OK, thanks. Indeed, there is no real overlap, but the buffer may point to the same location after get_buffer()
in ugrep:1164. So it copies to the same location. This is a bit of a dirty trick (I know what I'm doing) to eliminate unnecessary buffer allocations, since we already have a buffer so we don't need another one.
I prefer to use memmove()
instead of a guard in this case:
// move decompressed data to destination buf, which can be the same as the source buffer after get_buffer()
memmove(buf, buf_ + cur_, num);
I'll close this as resolved, since this is copy in place is harmless (our tests do not show any issues either) and the next release will have the patch in place.
Thank you!
I did quick smoke testing of 6.0.0 under valgrind on i586 and it reports the error:
Looks like address (
0x8e1f454
) is the same for src and dst and the buffer just [needlessly] copied to itself, so this all perhaps harmless, but this hiccups valgrind and prevent its use for smoke testing on i586. Curiously, on x86_64 the condition is not detected.With such test patch (to prove there is no other overlaps) error disappears: