Why does std::cout output disappear completely after NULL is sent to it

Question

It took me a while to figure out why some cout output seem to disappear into the ether. The culprit:

std::cout<< "This line shows up just fine" << std::endl; const char* some_string = a_function_that_returns_null(); if (some_string == 0)     std::cout<< "Let's check the value of some_string: " << some_string << std::endl;  std::cout<< "This line and any cout output afterwards will not show up" << std::endl; 

The output from the snippet above will be:

This line shows up just fine Let's check the value of some_string:      

So feeding a NULL into cout will disable all output afterward. Why? And how to fix it?

This doesn't happen all the time - a co-worker with the same code gets all the expected output. And in case you wonder why I can't just prevent feeding NULL into cout with a if statement: I'm working in a large codebase, and don't know where else this happens! All I know is the cout statements I put never showed up.

---

More info:

a_function_that_returns_null() is actually getenv("HOST"). I checked on the commandline via echo $HOST that the HOST variable is empty. If I do export HOST= (bash flavor), the output are all there. I have no idea what the HOST variable contains initially nor what getenv returns initially when before I modify the HOST variable; all I know is (some_string == 0) is true.

Answer 1

const char* some_string = a_function_that_returns_null(); 

Do you mean that it literally returns a null pointer?

[2003: 27.6.2.5.4]:

template<class traits> basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>& out, const char* s); 

3. Requires: s is non-null.

Then streaming some_string is Undefined Behaviour; you cannot dereference a pointer to get a string — even an empty one — if the pointer is not valid.

---

This doesn't happen all the time - a co-worker with the same code gets all the expected output

UB leads to unreliable symptoms. That you don't always get a crash can be slightly surprising because most modern OSs make a point of always SIGSEGVing when you try to dereference a null pointer.

However, from a C++ point of view, anything can happen; in your particular case, your standard library implementation may well be checking for a null pointer and setting an error flag on the stream instead of attempting to dereference the pointer. That is its prerogative.

(It's also probably why your subsequent stream operations are failing: attempting to write to a stream does nothing when there's an error flag set.)

For example, the libstdc++ that ships with GCC 4.6.0, despite naming s != 0 as a precondition, does do this:

00325       if (!__s) 00326     __out.setstate(ios_base::badbit); 00327       else 

However, you must not rely on this behaviour; it could change at any time!

---

So, simply don't do this. Stream a valid, but empty, string if you really must.

And what's wrong with std::string?

Answer 2

I'm fairly sure that cout << (char*)NULL has undefined behavior. I'm afraid that "Don't do that" is the best advice I can offer.