https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #11 from Paul Sanders <p.sanders at alpinesoft dot co.uk> --- > 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. Yes, that's very much my own personal preference, but as I dig into this more I can see there are problems with doing what I'm asking for. > Removing this longstanding behaviour now could break an unknown number of > programs which are (implicitly or explicitly) relying on this behaviour of > libstdc++. I think they'd have to be relying on it explicitly (i.e. they turn on badbit exceptions or check explicitly for badbit). Otherwise, they have a bug. Question is, how many are there out there? I doubt many are testing badbit. Not for this reason, anyway. There is however, some info at [cppreference](http://en.cppreference.com/w/cpp/io/ios_base/iostate) which supports your view. Passing in quite a few types as nullptr sets badbit (too many, IMO), but `char *` is not mentioned explicitly. So I suppose it's reasonable for people to expect that _all_ null pointers should be treated in the same way. It's a shame anyone on the standards committee ever thought that testing for null pointers in this way was useful but I suppose we're stuck with it now. Personally, I think it was a big mistake. > Failure to open a file sets failbit, not badbit. Noted, thank you, I'm not very familiar with iostreams. Forget that bit then. > The program did work fine though, and anybody can verify that it does so > intentionally, not by accident. Nice link, thank you, but that doesn't change the basic argument that many programs will not be working quite right because they accidentally passed in a null pointer and didn't expect the resulting behaviour of `ostream`. Still, I might in the end have to say here, sadly: c'est la vie.
