Hello!
Marshall Clow wrote:
After executing this code, what will the value of p3 be?
Under gcc/glibc, it will be NULL, because memcpy is marked with non-null attributes, and so the if (p==NULL) branch is removed.
(Yes, even though memcpy(x, y, 0) will not dereference the pointer)
This is undefined behaviour right?
The C standard says that all the memcpy arguments must be valid according to 7.1.4.. and there we have this text:
.... unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (.... or a null pointer, ...) .., the behavior is undefined.
It seems to me that it says that passing a null pointer to any C standard library function is undefined behaviour, unless it's explicitly stated otherwise.
Best regards,
Daniel Marjamäki
Hello!
Marshall Clow wrote:
After executing this code, what will the value of p3 be?
Under gcc/glibc, it will be NULL, because memcpy is marked with non-null attributes, and so the if (p==NULL) branch is removed.
(Yes, even though memcpy(x, y, 0) will not dereference the pointer)
This is undefined behaviour right?
Right.
The C standard says that all the memcpy arguments must be valid according to 7.1.4.. and there we have this text:
.... unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (.... or a null pointer, ...) .., the behavior is undefined.
It seems to me that it says that passing a null pointer to any C standard library function is undefined behaviour, unless it's explicitly stated otherwise.
My point was that gcc will use that information (specifically, the “not null” annotations on memcpy) to affect its codegen.
— Marshall