4

With regard to the issues copy vs. memcpy vs memmove(excellent info here, btw.), I have been reading up and it would seem to me, that unlike what is colloquially said, for example at cppreferenceNote: memcpy has been changed to memmove since taking this quote. --

Notes

In practice, implementations of std::copy avoid multiple assignments and use bulk copy functions such as std::memcpy if the value type is TriviallyCopyable

-- std::copy (nor std::copy_backward) cannot be implemented in terms of memcopy, because for std::copy only the beginning of the destination range must not fall into the source range, but for memcpy the entirety of the ranges must not overlap.

Looking at Visual-C++'s implementation (see the xutility header), we can also observe that VC++ uses memmove, but that one now has more relaxed requirements than std::copy:

... The objects may overlap: copying takes place as if the characters were copied to a temporary character array and then the characters were copied from the array ...

So it would appear that implementing std::copy in terms of memcpy is not possible, but using memmove is actually a pessimization. (a wee tiny bit of pessimization, possibly not measurable, but still)

To come back to the question(s): Is my summary correct? Is this a problem anywhere? Regardless of what's specified, is there even a possible practical implementation of memcpy that would not also fulfill the requirements of std::copy, i.e. are there memcpy implementations that break when the ranges partially overlap as allowed by std::copy?

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • 7
    First, the implementation of `std::copy` doesn't have to be strictly portable, and may utilize knowledge of the implementation details of `memcpy` (e.g. that it's actually OK to copy between overlapping regions, as long as they overlap the right way). Second, even if it chooses not to, it may still check ranges and defer to `memcpy` when they don't overlap (that is, most of the time). – Igor Tandetnik Oct 25 '13 at 20:23
  • 1
    libc++ and stdlibc++ call memmove as well, I changed that note on cppreference to say memmove. – Cubbi Oct 28 '13 at 22:14
  • http://stackoverflow.com/q/19585930/321013 – Martin Ba Oct 29 '13 at 09:22
  • http://vgable.com/blog/2008/05/24/memcopy-memmove-and-speed-over-safety/ – Martin Ba Oct 29 '13 at 09:23

1 Answers1

2

If the question is, whether it's possible to encounter an efficient memcpy implementation with enough undefined behavior to not trust it over overlapping ranges, then the answer is yes. :-)

Consider one possible implementation of memcpy on Power(PC) architecture: lmw instruction will load multiple consecutive words from memory into consecutive registers (which can be specified as a user defined range argument). stmw will then save the supplied register range back to memory. Thus, we are talking around ~100/200 bytes (32b/64b CPU) buffered by the CPU during a single memcpy iteration - plenty of data to spoil the target range if it overlaps with the source one, especially considering that CPU makes no promises about relative order of individual load and stores.

oakad
  • 6,945
  • 1
  • 22
  • 31
  • How about a compiler which, given `void f(char *p,char*q) { if (p!=q) doSomething();} void g(char *p,char *q) { f(p,q); memcpy(p,q,sizeof *p); }` will infer that the Standard imposes no requirements on the behavior of g when p==q, thus allowing the call to "doSomething();" to be made unconditional? – supercat Oct 31 '15 at 20:20