memmove doesn't move

Question

memmove doesn't really move memory isn't that right? It just copies memory from one region to other and allows those two regions to overlap. I'm asking this question because I just want to know why is this fnc called in very misleading manner.
For I understand that when something is moved from one place to the other, the "thingy" is after this operation in the other place and not in the first. And with memmove it doesn't work that way. Am I right?

Answer 1

You are right, it copies it. However, there is a difference between memmove and memcpy, because memmove can treat correctly the case when the buffers overlap, so it is recomended in these cases.

However, because of additional checks that memmove performs, when the buffers are small and surely does not overlap, memcpy is better.

Answer 2

The difference between memcpy() and memmove() is that memmove() is always safe to use, regardless of aliasing between source and destination. It is as though memmove() copies data to a temporary buffer first and then to the destination. memcpy() does not offer any aliasing guarantees. it may work as intended, but maybe not. If you know buffers cannot overlap, memcpy() is fine, and may in any given library use optimizations that allow it to be faster than memmove(). In another library memcpy() may actually just be memmove().

If you know src and dst cannot be aliases, it is safe to use memcpy(). If you don't know which one applies to you, use memmove().

Answer 3

The function is named as such because if the memory regions being copied do happen to overlap it is no longer a copy, since the original buffer is no longer unchanged. Therefore the original buffer should be considered unusable. Since you're using memmove not memcpy this is likely to be the case. Therefore the naming makes sense: semantically you're moving the data not copying it.

Answer 4

Memmove copies data from the source to the destination. It differs from memcpy in that it is guaranteed to work on overlapping memory regions.

Answer 5

Yes, memmove is really memcpy with the ability to handle overlapping blocks. Let's say you have an array, and you want to insert some new items at the begining (or remove some items), then symantically what you are doing is "moving" the (existing or remaining) items back and forth - I guess, and in that context, the name makes sense.

Answer 6

Yes, memmove is another variation on the copy. It does not "move" memory in the sense that the original bytes are no longer what they were before the operation. It is specifically to handle the case of overlapped memory.

How this is done depends on your architecture but I've seen it done two different ways:

• use a temporary buffer with two memcpy-type operations; or
• copy from the first byte going forwards or the last byte going backwards, depending on the overlap type (if any).

Answer 7

To answer your question about memmove()'s name: I think the name was intended to reflect support for moving ranges of elements in an array to another range in the array (for example, to make room for a new element at the start or inside the array).

As other answers mention, memcpy() can use optimizations techniques that aren't available to memmove() because memcpy() doesn't support memory regions that overlap, while memmove() does.

One thing you might want to consider is to still use memmove() instead of memcpy() by default unless you're working on an application where copy performance is critical. memcpy() can provide better performance (mainly because it can inlined more effectively, I think), but keep in mind this quote about the memcpy() implementation in the Linux kernel from a discussion about an application's incorrect use of the C library's memcpy():

In the kernel, the optimized x86 memcpy we use is actually a memmove(), because while performance is really important, so is repeatability and avoiding surprises (strictly speaking, we have two: the "rep movs" version for the case where that is supposed to be fast, and the open-coded copy version. The "rep movs" version is forwards-only and doesn't handle overlapping areas).