Can I call memcpy() and memmove() with "number of bytes" set to zero?

Question

Do I need to treat cases when I actully have nothing to move/copy with memmove()/memcpy() as edge cases

int numberOfBytes = ...
if( numberOfBytes != 0 ) {
    memmove( dest, source, numberOfBytes );
}

or should I just call the function without checking

int numberOfBytes = ...
memmove( dest, source, numberOfBytes );

Is the check in the former snippet necessary?

Answer 1

No, the check is not necessary. Relying on zero being handled properly is fine and very reasonable, in my opinion. It might be worth commenting.

Answer 2

The documentation of memmove and memcpy says this:

The function does not check for any terminating null character in source — it always copies exactly num bytes.

The opengroup documentation says basically the same thing.

So, given that it copies "exactly num bytes", it will copy zero bytes when num = 0, and thus it shouldn't be necessary to treat this as a special case.

Answer 3

From the C99 standard (7.21.1/2):

Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4. On such a call, a function that locates a character finds no occurrence, a function that compares two character sequences returns zero, and a function that copies characters copies zero characters.

So the answer is no; the check is not necessary.

Answer 4

As said by @You, the standard specifies that the memcpy and memmove should handle this case without problem; since they are usually implemented somehow like

void *memcpy(void *_dst, const void *_src, size_t len)
{
    unsigned char *dst = _dst;
    const unsigned char *src = _src;
    while(len-- > 0)
        *dst++ = *src++;
    return _dst;
}

you should not even have any performance penality other than the function call; if the compiler supports intrinsics/inlining for such functions, the additional check may even make the code a micro-little-bit slower, since the check is already done at the while.