/Does/ memmove use an intermediate buffer?

Question

This is more a question out of curiosity than anything important, but I was just wondering about the following snippet in the memmove documentation:

Copying takes place as if an intermediate buffer were used

(emphasis mine). The formulation suggests to me that whether an intermediate buffer is used, is specific to the compiler implementation.

If you would ask me to write memmove, I would probably automatically do the following:

allocate n bytes on the heap
memcpy the source to the temp
memcpy the temp to the destination
free the buffer

I was hoping anyone could ...

... confirm whether the formulation is only because it's easier for users to visualize what is going on, without fixing that specific implementations actually have to use an intermediate buffer;
... shed some light on the actual implementation in some common C++ compilers (like gcc or Visual C++) - for example, does it use a buffer and does it check for overlap so it can memcpy directly;
... maybe point out the blatantly obvious error / inefficiency in my simple algorithm above.

From what I understand, it's phrased like that to make you sure it correctly handles cases of copying inside SAME BUFFER correctly. Which might seem to require intermediate buffer in some cases. — Agent_L, Apr 07 '14 at 14:17
'As if' means that data will not be destroyed when source and destination areas overlap. This is simply achieved by copying in appropriate direction, with addresses being incremented or decremented, depending on which part overlaps. However if displacement is, say, 1 byte then the effectivness drops drmatically - data would have to be copied by byte instead of, say, 4-byte chunks. Then the CPU register might be used as a buffer - but still no additional memory buffer is needed. — CiaPan, Apr 07 '14 at 14:18
Thanks @CiaPan, that's the kind of thing I'm looking for. Using a buffer would prevent this, but would be inefficient for big non-overlapping blocks. So I was wondering how much "intelligence" for picking an appropriate strategy `memmove` has in this respect. — CompuChip, Apr 07 '14 at 14:19
It does not take much intelligence. It will iterate the source bytes forwards or backwards, depending on how the destination overlaps the source. — Hans Passant, Apr 07 '14 at 14:27

score 5 · Accepted Answer · answered Apr 07 '14 at 14:20

Indeed. "As if" means that it must behave like that's what it did; but doesn't constrain the implementation to actually do that. The only required behaviour is that the destination buffer ends up with the correct bytes from the source buffer, whether or not the buffers overlap.
A common implementation is to copy bytes forwards from the beginning of the buffer if the destination starts before the source, and backwards from the end otherwise. This ensures that the source bytes are always read before they're overwritten, if there is an overlap.
There are no errors, unless the allocation fails. The inefficiencies are allocating and freeing the temporary buffer, and copying each byte twice rather than once.

score 3 · Answer 2 · answered Apr 07 '14 at 14:20

3

You are absolutely right on the #1 - the description is to help users visualize what's going on logically, not to explain how it is implemented.

However, no sane implementation would actually go about doing it with an expensive temporary buffer, because all you need to do to avoid double-copying is to decide if you want to copy from the beginning or from the end. Here is a sample implementation that does precisely that.

The only problem with your algorithm is that it can run your system out of memory when it is not necessary: imagine that your program tries to move a buffer sized at 60% of the allowed total memory to see an example of when it would happen.

answered Apr 07 '14 at 14:20

Sergey Kalinichenko

714,442
84
1,110
1,523

Interesting to see that your sample implementation actually uses the same code for copy and move! – CompuChip Apr 07 '14 at 15:17
@CompuChip Why not? After all, copy does not need to break when it's passed invalid arguments :-) – Sergey Kalinichenko Apr 07 '14 at 15:44
Yeah, why not indeed. I just did not realize this until I saw it! – CompuChip Apr 07 '14 at 16:14

score 2 · Answer 3 · answered Apr 07 '14 at 14:21

One of the first optimization opportunities that comes to mind is to do a plain memcpy() if the buffers do not overlap. Due to the flat nature of the (virtual) address space, it's easy to check. I looked at the glibc and Android implementations, and both do this (the Android one is easier to follow for the uninitiated).

Allocating memory on the heap is probably a no-go, because it will be quite slow (dynamic allocation is not that cheap).

If the buffers do overlap, we could optimize copying of the parts which do not, and for the rest we might use a small scratch buffer, but that would be stack-allocated if indeed any allocation is needed at all. The Android one copies just one byte at a time; we can do better on amd64 but that's the same sort of optimization that would already be done in memcpy. The glibc one copies either forward or backward depending on the nature of the overlap (that's what "BWD" in the source refers to).

score 1 · Answer 4 · answered Apr 07 '14 at 14:25

The implementation does not matter. The wording is to guarantee that memory will properly be handled.

char buf[] = { 0x11, 0x22, 0x33, 0x00 };
memcpy(buf, buf + 1, 3);

could result in buf being { 0x11, 0x11, 0x11, 0x11 }.

where as

char buf[] = { 0x11, 0x22, 0x33, 0x00 };
memmove(buf, buf + 1, 3);

is guaranteed that buf will be { 0x11, 0x11, 0x22, 0x33 }.

/Does/ memmove use an intermediate buffer?

4 Answers4