It would be good to understand the reason why the standard library isn't more protective against nullptr.

Defensive coding would suggest that it would be better to not crash if a null is supplied. It is such a common thing to do. If it takes a pointer, then a pointer should be a valid value or at least handled. Whether the interface treats it the same as "" is a matter for the interface definition.

For this reason I always define an input parameter as a reference if a pointer value is not a valid input. This pushes the onus onto the caller to ensure they check a pointer if that's what they have. If I want a pointer then the responsibility it with the function to ensure it does not crash with a nullptr.

Until someone enlightens me, I see this as a bug in the standard library and have been caught out by it on a few occasions.