https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Paul Sanders from comment #8)
> Thanks for your comments.  I can see there are two sides to this.
> 
> I was in the middle of composing the tract below.  I'll include that anyway
> because it took me ages to type.  There's a bit at the end about people who
> might get bitten if you do make this change, but a plausible alternative to
> crashing the program might be to (a) print "(null)", and (b) leave the
> badbit alone.  I think I'd settle for that, I actually quite like the way
> the printf family behaves.

That would be another valid outcome of undefined behaviour, but would make it
much harder to detect the problem. Setting badbit makes it possible to detect
and take action (including calling std::abort() or throwing an exception, if
you want to).

> My view of the badbit, BTW, is that it's not there to catch programming
> errors - it's there to report adverse events that come up at runtime (e.g.
> cannot open file).  I expand on that below.

Failure to open a file sets failbit, not badbit.

> After all, ostream would likely crash if the pointer was invalid, so what's
> so special about NULL?

It's detectable.

> [Additional note: I can see if you change the current behaviour you might
> get a bit of flak from people whose programs "used to work fine".  Well,
> they didn't, and they should be grateful to you for alerting them to that
> fact.]

The program did work fine though, and anybody can verify that it does so
intentionally, not by accident:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ostream.tcc;h=e02ba55a6262b96ead90595e1aad56119a965844;hb=HEAD#l323

As the standard says:

  Permissible undefined behavior ranges from ignoring the situation completely
  with unpredictable results, to behaving during translation or program
  execution in a documented manner characteristic of the environment (with or
  without the issuance of a diagnostic message), to terminating a translation
  or execution (with the issuance of a diagnostic message).

Reply via email to