I just tested the following on my setup (gcc 4.8.2, recent uClibc), and it runs fine:
#include <string.h>
int main(int argc, char **argv) {
char buf[4], fub[4] = "abc";
memmove(buf, fub, 0);
memmove(buf, NULL, 0);
memmove(NULL, fub, 0);
memmove(NULL, NULL, 0);
return 0;
}
It also works with memcpy
. So it's clear that passing NULL
s to these functions works OK in practice, on at least some setups. But I want to code defensively, and am trying to determine whether any C standard permits me to rely on this behavior, or whether it's undefined or implementation-defined.
This answer points out that the C99 standard does specify that passing a size of 0 to these functions shall be valid. Here is the text, from section 7.21.1:
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.
Reading section 7.1.4, on the other hand, seems to say that passing NULL
s is not defined:
Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.
Is that your understanding too? Can anyone confirm/deny whether the standard leaves this behavior undefined?
I'm mainly targeting C99, but feedback about other C standards is also welcome.