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

[peturr02 at ru dot is]

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 peturr02 at ru dot is  2003-07-01 10:08 -------
Martin Sebor wrote:
> I'm not sure I follow you here. Are you concerned that the text
> contradicts itself in that if badbit is not set in exceptions
> but failbit is, calling setstate (failbit) is not allowed to
> throw failure? I don't think that is the intent of the text.

I don't think there is any doubt that setstate(failbit) should throw if
failbit is set in exceptions(), the question is whether the (un)formatted
input/output functions should catch those exceptions. Some parts of the
standard imply that the exceptions should be caught, some imply that they
should not be caught.
 
>> 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.
> 
> I'm not too familiar with the libstdc++ implementation so I can't
> speak for it but I can't think of any place in the standard that
> mandates or allows this behavior. Do you have an example?

basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& sb,
                  char_type delim );

Notice bullet 4:
  an exception occurs (in which case, the exception is caught but not rethrown).
I read this to mean that exceptions thrown by either operations on sb or on
rdbuf() should not propagate from this function, even if badbit is set in
exceptions(). This is inconsistent with the rest of the (un)formatted
input/output functions. This function also differs from
operator>>(basic_streambuf* sb) which rethrows exceptions from sb if failbit is
on in exceptions().
 
> That looks like a typo in the resolution. I would expect the
> function to behave as if the text read
[...]

Yes, that makes sense. 

Petur