https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535
--- Comment #6 from Vittorio Zecca <zeccav at gmail dot com> --- The cost of adding "if(base_name_len)" is two x86-64 machine instructions cmpl $0, -20(%rbp) je .L2 Six instructions follow then call memcpy which is not exactly a NOP even with base_name_len==0 In my opinion two machine instructions to avoid a useless and undefined memcpy are a bargain. It is not undefined behaviour to pass a NULL pointer to an arbitrary function, but it is undefined to pass it to memcpy. And it seems to me that after memcpy(dest,src,len) the statement "if(src)" is always TRUE because the optimizer assumes src!=NULL The following is from https://gcc.gnu.org/gcc-4.9/porting_to.html Null pointer checks may be optimized away more aggressively GCC might now optimize away the null pointer check in code like: int copy (int* dest, int* src, size_t nbytes) { memmove (dest, src, nbytes); if (src != NULL) return *src; return 0; } The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash. The example above needs to be fixed to avoid the invalid memmove call, for example: if (nbytes != 0) memmove (dest, src, nbytes); This optimization can also affect implicit null pointer checks such as the one done by the C++ runtime for the delete[] operator.