Yet, it happens:

https://nvd.nist.gov/vuln/detail/CVE-2017-14064

https://nvd.nist.gov/vuln/detail/CVE-2015-3182

https://nvd.nist.gov/vuln/detail/CVE-2017-13748

etc.

This is true. Although they did say "copy a string", not use strdup to copy a thing that is not a string. :)

Yes, that's one of the three CVE's I posted ;).

You got me thinking about ways one could get strdup wrong:

- input is not a string -> possible UB

- input is a string, but the character encoding wasn't what you thought -> possible UB

- input is a string, but it was the pointer-plus-length kind -> possible UB

- input is modified by another thread -> possible UB

- strdup called from within a signal handler -> possible UB

- failure to handle error return values -> possible UB

- failure to free the memory when it's no longer needed -> memory leak

- freed the memory more than once -> possible UB

- used the memory after freeing it -> possible UB

I've personally seen several of these in real-world code.

How did I forget:

- forget to #include string.h, so strdup is implicitly declared, so its return type is int, which implicitly converts to char*, so everything still compiles -> possible UB