This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work


Jerry Quinn wrote:
> Martin Sebor writes:
>  >  Pétur Runólfsson wrote:
>  >  ...
>  >  > 
>  >  > Note the "during input". I read that as meaning that 
> this refers only
>  >  > to exceptions thrown by the call to num_get::get(), not 
> to exceptions
>  >  > thrown from other functions the extractors may call.
>  >  
>  >  The general requirements on what causes exceptions to be caught
>  >  and rethrown are buried in 27.6.1.1, p1-4. According to the text
>  >  only calls to members of streambuf are supposed to be checked
>  >  for exceptions.

Do you mean that "these called functions" in p4 only refers to
rdbuf()->sbumpc() and rdbuf()->sgetc() and not setstate()?

The part "as if the called function had returned a failure
indication" implies that setstate is not included (after all, it
doesn't return failure indications), but the part "If badbit is
on in exceptions(), [...], otherwise it does not throw anything"
implies that s >> x will only throw if
(s.exceptions() & ios::badbit) != 0, so setstate should be
included (but this contradicts the resolution to DR 64).

>  >  But because it's not possible to distinguish
>  >  between an exception thrown by, say, a (virtual) member function
>  >  of ctype called from num_get::get() and one thrown by a (virtual)
>  >  streambuf member called (indirectly, via an istreambuf_iterator
>  >  member) from num_get::get(), the requirement cannot realistically
>  >  be taken to mean just exceptions thrown during a call to num_get
>  >  ::get() and not, for instance, ctype::is() called by the istream
>  >  ::sentry ctor.

I agree. It seems reasonable to set badbit if say,
use_facet<ctype<CharT> >(getloc()) fails (since this makes the stream
unreadable, i.e. bad), but neither 27.6.1.1 nor 27.6.1.2.1 says
anything about this one way or the other if we take "these called
functions" and "during input" to mean only rdbuf->sbumpc() and
rdbuf()->sgetc().

>  >  IMO, stream members should consistently catch all
>  >  exceptions from any functions they may call.
> I buy this :-)

I agree, however I also think that exceptions() should be consistent
with itself, that is, setting exceptions(foobit) should simply mean
that whenever foobit is set in rdstate(), an exception is thrown.
In the current implementation (and to some extent, the standard)
the effect of exceptions(foobit) differs between the various I/O
functions and depends on the value of foobit.

> Given that we catch all the exceptions,

IMHO this is never stated unambiguously in the standard.

> when do we
> rethrow?  The original text says rethrow if badbit is set in the
> exception mask.  DR64 says to rethrow if failbit is set and the
> exception mask has failbit set.  So, does it make sense to change

No. DR 64 only refers to
basic_istream<C, T>::operator>>(basic_streambuf<C, T>* sb). It only
states that if operations on sb [1] throw then failbit should be set
in rdstate(), and if (exceptions() & failbit) != 0, the exception is
rethrown. It does not override the requirements on formatted input
functions, so exceptions thrown by operations on rdbuf() should
cause badbit to be set, and only be rethrown if
(exceptions() & badbit) != 0. The reason I brought up this DR is
that the resolution states that exceptions thrown by
setstate(failbit) should not be caught.

Petur

[1] Actually, the resolution talks about exceptions thrown "while
extracting characters from sb" which seems rather silly as the
function extracts characters from rdbuf() and inserts them into
sb.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]