[Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work

["sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093



------- Additional Comments From sebor at roguewave dot com  2003-07-24 22:34 -------
Subject: Re:  Regression: Setting failbit in exceptions
 doesn't work

peturr02 at ru dot is wrote:

...
> 
> That's not the latest version; revision 26 (post-oxford) is here:
> 
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html
> 
> (Why haven't the links been updated?)

Hmm, dunno. I sent an email to have them updated.

> 
> The only semantics for exceptions() that make any real amount of
> sense are that after a call to an (un)formatted input/output
> operation R on a [io]stream s and object x:
> 
> s R x;
> 
> 1) If (s.rdstate() == 0) before the call, an exception is thrown
> if and only if after the call (s.rdstate() & s.exceptions()) != 0;
> 2) The value of s.rdstate() after the call does not depend on
> the value of s.exceptions().

Agreed.

> 
> The implementation of operator>> you described seems to
> achieve exactly this.

Yes. Our implementation tries to follow 1) and 2) above.

> 
> Unfortunately the description of basic_ios::exceptions() gives
> no such guarantees, nor any other hint whatsoever about what
> the intent of exceptions() was. Even worse, the rationale for
> closing DR 399 as NAD indicates that property 1) isn't supposed
> to hold.

Again, I don't think the intent of the original design was
anything other than your 1) and 2) above, despite the status
of 399 or 309.

> 
> 
>>I don't think this could ever pass. The intent of badbit is
>>to indicate some unrecoverable error in the stream buffer.
>>Setting it as a result of failbit being set in both state
>>and exceptions would defeat the purpose of the bit.
> 
> 
> I agree. If property 2) doesn't hold, badbit is meaningless
> if either failbit or eofbit is set in exceptions().
> 
> Perhaps I am reading to much into the words "if an exception is
> thrown during input" in 27.6.1.2.1 and the intent is not to
> catch exceptions thrown during the sentry constructor, whether
> by use_facet, ctype::is or rdbuf()->underflow().

The intent as I understand it from the email discussions that
took place years ago on the reflector, was to accommodate, at
least to some extent, classic iostreams, that didn't throw
exceptions and didn't expect any functions called from the
iostream members to do so, either.

The text in iostreams is probably slightly out of sync with
locale, which came later. My guess is that whoever wrote it
did not anticipate any virtual functions other than members
of streambuf to be called from iostream members. The only
sane and consistent thing to do, IMHO, is to have iostreams
behave according to your 1) and 2) above.

> 
> (Or perhaps the "no clarification needed" part of the rationale
> for DR 309 simply means that 27.6.1.2.1 already requires
> sentry::sentry() to catch exceptions; but if this is accepted
> one might equally argue that 27.6.1.2.1 requires num_get::get
> to catch exceptions. I don't think this can be intended.)

I think one just needs to take the standard with a big
grain of salt when it comes to error handling in iostreams.

Martin