Don't pass NULL to strdup or any string functions since the spec does not allow them:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/strdup.html

It's surely an application bug to pass NULL to strdup, but shouldn't the str* functions deal with invalid arguments more gracefully? Rather than simply giving a segfault in libc to user. I'm not sure...

I think strdup just in turn calls memcpy and if the source pointer is not valid, the behavior is undefined.  Closing.

(In reply to Eryu Guan from comment #2)
> It's surely an application bug to pass NULL to strdup, but shouldn't the
> str* functions deal with invalid arguments more gracefully? Rather than
> simply giving a segfault in libc to user. I'm not sure...

No.

The GNU C Library specifically does not check for NULL pointers and we document our policy in "Style and Conventions" -> "Invalid Pointers" on our project wiki:

https://sourceware.org/glibc/wiki/Style_and_Conventions#Invalid_pointers

~~~
9. Invalid pointers

The GNU C library considers it a QoI feature not to mask user bugs by detecting invalid pointers and returning EINVAL (unless the API is standardized and says it does that). If passing a bad pointer has undefined behavior, it is far more useful in the long run if it crashes quickly rather than diagnosing an error that is probably ignored by the flaky caller.

9.1. NULL pointers

If you're going to check for NULL pointer arguments where you have not entered into a contract to accept and interpret them, do so with an assert, not a conditional error return. This way the bugs in the caller will be immediately detected and can be fixed, and it makes it easy to disable the overhead in production builds. The assert can be valuable as code documentation. However, a segfault from dereferencing the NULL pointer is just as effective for debugging. If you return an error code to a caller which has already proven itself buggy, the most likely result is that the caller will ignore the error, and bad things will happen much later down the line when the original cause of the error has become difficult or impossible to track down. Why is it reasonable to assume the caller will ignore the error you return? Because the caller already ignored the error return of malloc or fopen or some other library-specific allocation function which returned NULL to indicate an error.

In summary:

    * If you have no contract to accept NULL and you don't immediately dereference the pointer then use an assert to raise an error when NULL is passed as an invalid argument.

    * If you have no contract to accept NULL and immediately dereference the pointer then the segfault is sufficient to indicate the error.

    * If you have a contract to accept NULL then do so. 
~~~