I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80, 0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
Is that normal? Either way, the C standard says that source and
destination can’t overlap for memcpy, otherwise the results are
undefined. I imagine that on any sane implementation having both as
being the same is effectively a no-op, but it may still be better to
avoid in the first place.
Comments?
Being the same != overlap.
imagine void* x == 42; void* y == 44;
memcpy(y, x, 10);
One should use memmove() for overlapping memory ranges.
(I haven’t looked at the source if it even makes sense to have
overlapping memory ranges there etc)
Cheers,
DanielAm 23.06.2014 21:41, schrieb Sik the hedgehog:
I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80, 0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
Is that normal? Either way, the C standard says that source and
destination can’t overlap for memcpy, otherwise the results are
undefined. I imagine that on any sane implementation having both as
being the same is effectively a no-op, but it may still be better to
avoid in the first place.
Comments?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Being the same is still a specific case of overlap, and being an
overlap is the actual issue 
2014-06-23 20:04 GMT-03:00, Daniel Gibson :> Being the same != overlap.
imagine void* x == 42; void* y == 44;
memcpy(y, x, 10);
One should use memmove() for overlapping memory ranges.
(I haven’t looked at the source if it even makes sense to have
overlapping memory ranges there etc)
Cheers,
Daniel
Am 23.06.2014 21:41, schrieb Sik the hedgehog:
I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80,
0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
Is that normal? Either way, the C standard says that source and
destination can’t overlap for memcpy, otherwise the results are
undefined. I imagine that on any sane implementation having both as
being the same is effectively a no-op, but it may still be better to
avoid in the first place.
Comments?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Yeah, sure, being the same is a case of overlap, but not the other way
around, so a simple check if(src != dst) is not enough to avoid
potential problems :)Am 24.06.2014 01:11, schrieb Sik the hedgehog:
Being the same is still a specific case of overlap, and being an
overlap is the actual issue
2014-06-23 20:04 GMT-03:00, Daniel Gibson <@Daniel_Gibson>:
Being the same != overlap.
imagine void* x == 42; void* y == 44;
memcpy(y, x, 10);
One should use memmove() for overlapping memory ranges.
(I haven’t looked at the source if it even makes sense to have
overlapping memory ranges there etc)
Cheers,
Daniel
Am 23.06.2014 21:41, schrieb Sik the hedgehog:
I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80,
0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
Is that normal? Either way, the C standard says that source and
destination can’t overlap for memcpy, otherwise the results are
undefined. I imagine that on any sane implementation having both as
being the same is effectively a no-op, but it may still be better to
avoid in the first place.
Comments?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I reported this bug in March, with a patch that fixes it.
https://bugzilla.libsdl.org/show_bug.cgi?id=2467On 23.06.2014 21:41, Sik the hedgehog wrote:
I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80, 0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
–
Rainer Deyke (rainerd at eldwood.com)
Ah, thanks for the reminder!
https://hg.libsdl.org/SDL/rev/c9be8299ba6bOn Tue, Jun 24, 2014 at 1:20 AM, Rainer Deyke wrote:
On 23.06.2014 21:41, Sik the hedgehog wrote:
I was testing my game on valgrind to hunt down a bug and noticed this:
==12795== Source and destination overlap in memcpy(0xffefffd80,
0xffefffd80, 32)
==12795== at 0x4C2F71C: memcpy@@GLIBC_2.14 (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12795== by 0x5057C24: SDL_OpenAudio_REAL (SDL_audio.c:786)
==12795== by 0x42B95C: init_sound (sound.c:188)
==12795== by 0x41CA03: main (main.c:129)
I reported this bug in March, with a patch that fixes it.
https://bugzilla.libsdl.org/show_bug.cgi?id=2467
–
Rainer Deyke (rainerd at eldwood.com)
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
One should use memmove() for overlapping memory ranges.
(I haven’t looked at the source if it even makes sense to have
overlapping memory ranges there etc)
Fwiw, things like strcpy() in glibc will absolutely fail if there’s
overlap and would need memmove() in that scenario (anecdotally, I’ve
seen this mistake work correctly anyhow on Mac OS X’s and Microsoft’s C
runtimes and only fail on glibc, but it’s a real thing that happens in
real life).
–ryan.