https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #10) > As a data point, calling printf ("%s", p) does lead to a segfault in Glibc > for a null p because GCC turns the call into puts(p) Only when optimization is enabled. I'm not suggesting we should print "(null)", that would be crazy, I'm just demonstrating that expecting a segfault for this kind of error is not a safe or valid assumption. > which doesn't have the > same feature (see https://sourceware.org/bugzilla/show_bug.cgi?id=5618 for > the background). > > I think most users prefer invalid uses of pointers to fail loudly so they > can be caught early. Few users expect output functions to fail, and even > fewer bother to check for failures when writing to standard streams. Agreed, but this code has been present since r53839 in 2002, and there's an explicit test for that behaviour: testsuite/27_io/basic_ostream/inserters_character/char/8.cc This is not an accident, it's a supported feature (and arguably documented, by the code and the test). > Besides the inserter without the test resulting in more efficient code and > GCC emitting a warning when a null pointer is passed to it (it doesn't now > even though it should because of the strlen call), leaving it to the > compiler to deal with can also lead to better code downstream thanks to > -fdelete-null-pointer-checks. I think there would need to be a period of deprecation and an optional assertion enabled by _GLIBCXX_ASSERTIONS before we can do that (assuming we want to). If we were starting from scratch I wouldn't add the check (e.g. see the patch at https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00768.html that I proposed today) but it's far too late to just turn this into a segfault because somebody on stackoverflow found it surprising and doesn't know how to check iostreams for errors.