I ran into strange behavior when using the Aztec linear system solver library. Using valgrind, I found out that this library does a memcpy on overlapping buffers. Specification says that behavior of memcpy on overlapping buffers is not defined.
It turns out that memcpy on many machines has the same behavior as if you would do it with a for loop and therefore you can safely copy from a higher source to a lower destination:
for(int i = 0; i < len; i ++)
dest[i] = source[i];
BUT on our large cluster, memcpy of overlapping buffers has a different behavior which leads to problems.
Now I wonder whether the overlapping memcpy in the library is normal or just caused by another bug in my code. Since the library is widely used I assume that the memcpy issue should have been discovered earlier. On the other hand, it's still possible that the vast majority of the memcpy implementations behave like the for loop and therefore nobody ever encountered this problem.
- Can anyone tell me about his experiences with overlapping
memcpyon various machines? - Which part of my computer system does actually provide
memcpy?
I'd like to point out that question is about the practical experience with various implementations, not about what the specification says.
Answer
I've done some research on this in the past... on Linux, up until fairly recently, the implementation of memcpy() worked in a way that was similar enough to memmove() that overlapping memory wasn't an issue, and in my experience, other UNIXs were the same. This doesn't change the fact that this is undefined behavior according to the standard, and you are just lucky that on some platforms it sometimes works -- and memmove() is the standard-supported right answer.
However, in 2010, the glibc maintainers rolled out a new, optimized memcpy() that changed the behavior of memcpy() for some Intel core types where the C standard library is compiled to be faster, but no longer works like memmove() [1]. (I seem to recall also that this is new code triggered only for memory segments larger than 80 bytes). Interestingly, this caused things like the Linux version of Adobe's Flash player to break[2], as well as several other open-source packages (back in 2010 when Fedora Linux became the first to adopt the changed memcpy() in glibc).