When studying the sample code for this question I had assumed it was Undefined Behaviour which was preventing subsequent uses of std::cout
from printing. But it turns out that attempting to print a null pointer caused std::ios_base::badbit
and std::ios_base::failbit
to be set in its stream state which was the real cause for its being non-operational. Because of this, I am now curious if it really is Undefined Behaviour to (attempt) to print a null-pointer. So here are my questions:
Is it Undefined Behaviour to print a null-pointer? If so, what is it about the stream inserter that would cause this? I'm pretty certain the inserter is smart enough to not dereference a null-pointer.
I would also like to know why the inserter sets its error mask when encountering a null-pointer in this context (specifically badbit
). Why doesn't it treat it like the termination of a string literal?
I don't have a Standard handy, and I only found one source thus far that unfortunately led to a dead link.
basic_ostream
's operator<<(basic_ostream<>&, const char*)
function requires that the char*
is non-null - it is designed to print the string the pointer points to. So it is undefined behavior to send a null char*
to cout
. (See C++11 27.7.3.6.4/3 "Character inserter function templates").
However, basic_ostream
's operator<<(basic_ostream<>&, const void*)
function simply prints the value of the pointer, so a null pointer will work properly with that overload.
gcc ostream.tcc
line 319:
template<typename _CharT, typename _Traits>
basic_ostream<_CharT, _Traits>&
operator<<(basic_ostream<_CharT, _Traits>& __out, const char* __s)
{
if (!__s)
__out.setstate(ios_base::badbit);
gcc is simply performing a check that the standard does not guarantee, which is fine because it's undefined anyway.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With