-1

I try to print a nullptr to screen, and:

int* ptrA = nullptr;
std::cout<<ptrA<<"\n"; // print 0
char* ptrB = nullptr;
std::cout<<ptrB<<"\n"; // print nothing, program exit with code 0
... // never execute

I thought the compiler(g++ 4.8.4) may warning me that I should not try to cout a nullptr. the fact is: the program aborted, with '/test has exited with code 0 (0x00000000)', act like it terminals normally.

Why? I mean, if I do something wrong, or what does this designed to be?

thanks

thanks to all, I knew the behavior can be undefined, for a char* to be a string, or to print the address. And was adviced to never do this. I just wonder why the program didn't tell me anything, like warning, assert or exit with a code like -1, anything else. Is it the compiler's designed behavior?

Liz Wang
  • 1
  • 2
  • The simple answer is, it's not a very high priority thing. C++ often errs on the side of assuming the programmer knows what they are doing and provides few training wheels. You may find thins interesting: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 You might also read some articles on the difficulties of static analysis and false positives. – Retired Ninja Sep 29 '17 at 03:39
  • I bet it did exit with code -1 (or some other code) – user253751 Sep 29 '17 at 04:56
  • To people who are directed by search engine to this page, you should read the answer from original "duplicated" question as stackoverflow hints. In brief, the program did exit with code 0 (i.e. SUCCESS). Although the [C++ standard requires that the `char*` pointer to be non-null](https://eel.is/c++draft/ostream.inserters.character), implementations generally do not just dereference it blindly, instead, they check the null-ness, and set `std::cout` to a "bad" state if `nullptr` is passed, so the following `opereator <<` won't be performed at all. – zerox Apr 14 '23 at 03:21

2 Answers2

0

char*s are the canonical string implementation in C, and unfortunately they are very common with C++ as well.

Due to that reason, outputting a char* will not output the address held by that pointer, but instead, it will print the string pointed by that pointer.

An implementation may look like this:

std::ostream& operator<<(std::ostream& os, const char* data)
{
  while (*data)
  {
    os << *data;
    data++;
  }
  return os;
}

Since it dereferences the pointer you give to it, passing a (char*)nullptr) to this function invokes undefined behaviour, and aborting is as good behaviour as any other in that case.

Fatih BAKIR
  • 4,569
  • 1
  • 21
  • 27
0

When dealing with ostream, a char* is different from other kinds of pointers, because there is an operator<< specifically designed to treat a char* as a null-terminated C string.

Your program aborts because you are passing operator<< a char* pointer that:

  • points to memory you do not own, or
  • points to memory you do own, but is not a proper null-terminated C string, or
  • is NULL

All of these things invoke undefined behavior, which means the compiler is being really nice to you by simply aborting your program instead of doing something horrid.

To print the value of a char* pointer, cast it to a void*.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Dúthomhas
  • 8,200
  • 2
  • 17
  • 39
  • 1
    You did not mention this in your list, but passing a NULL `char*` pointer to `operator<<` is *undefined behavior*, which can also lead to termination if `operator<<` dereferences it – Remy Lebeau Sep 30 '17 at 00:29
  • It is not the *compiler* that aborts the program. More likely, invoking `operator<<` with invalid input is causing an exception to be thrown that is not being caught. An uncaught exception will call `std::terminate()`, and by default it calls `std::abort()` to abort the program. – Remy Lebeau Sep 30 '17 at 02:12
  • LOL, simplifications for OP always get feedback. Yes, runtime is aborting program; I contend that runtime does what compiler designs it to do. – Dúthomhas Sep 30 '17 at 04:02