There is no problem with memcpy other than that you can't use a null pointer. You can memcpy zero bytes as long as the pointer is valid. This works in a good many circumstances; just not circumstances where the empty array is represented by not having an address at all.<p>For instance, say we write a function that rotates an array: it moves the low M bytes to the top of the array, and shuffles the remaining M - N bytes down to the bottom. This function will work fine with the zero byte memmove or memcpy operations in the special case when N == 0, because the pointer will be valid.<p>Now say we have something like this:<p><pre><code> struct buf {
char *ptr;
size_t size;
};
</code></pre>
we would like it so that when the size is zero, we don't have an allocated buffer there. But we'd like to support a zero sized memcpy in that case: memcpy(buf->ptr, whatever, 0) or in the other direction likewise.<p>We now have to check for buf->ptr being buf in the code that deals with resizing.<p>Here is a snag in the C language related to zero sized arrays. The call malloc(0) is allowed to return a null pointer, or a non-null pointer that can be passed to free.<p>oops! In the one case, the pointer may not be used with a zero-sized memcpy; in the other case it can.<p>This also goes for realloc(NULL, 0) which is equivalent to malloc(0).<p>And, OMG I just noticed ...<p>In C99, this was valid realloc(ptr, 0) where ptr is a valid, allocated pointer. You could realloc an object to zero.<p>I'm looking at the April 2023 draft (N3096). It states that realloc(ptr, 0) is undefined behavior.<p>When did that happen?