Ok, is the memory block that memmove() moves deallocated or is the moved memory block still allocated in it's original location?

It doesn't seem to say in the documentation.

It seems like it would not.  memmove() describes itself as correctly overwriting the destination memory even if the source memory overlaps it.

Also, *src is marked const.  That should tell you right there.  The pointer is not changed.  :p

[quote author=MyndFyre link=topic=13515.msg137611#msg137611 date=1134579950]
It seems like it would not.  memmove() describes itself as correctly overwriting the destination memory even if the source memory overlaps it.

Also, *src is marked const.  That should tell you right there.  The pointer is not changed.  :p
[/quote]
Aight, thanks.  I'm nub.

Just to clarify, memmove() and memcpy() are about copying the values in the memory.  They don't know or care how the memory is allocated.  It could be backed by the stack, the heap, or a memory mapped file.  They're really just smarter versions of the following loop:

[code]
for (i = 0; i < end; ++i)
    dest[i] = src[i];
[/code]

They're smarter in that they can do block copies (not byte-sized), if appropriate.  memmove is also documented to know when running the loop as written will cause undesired output.  Consider if dest = src + (end / 2).  Then the second half of source is the first half of dest, so running my loop above would corrupt the output.  memmove will handle this case by using a different looping construct.  memcpy will not.  Thus, memcpy may be marginally faster since it doesn't do that extra safety check.

To reiterate my original point, neither knows anything about allocations, so it cannot move an allocation -- only the bytes inside that allocation.

Particularly, memcpy is likely to be unrolled into some mov's if you do it on a small buffer, while memmove mostly will not.