[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-24 15:47 -------
Martin Sebor wrote:
> My feeling is that if setstate() should end up throwing an exception
> some exception should always propagate out of the calling function.

I would like to agree, but the current proposed resolution and rationale
for DR 309 says otherwise:

  The LWG feels that no clarification of EH policy is necessary: the
  standard is precise about which operations sentry's constructor
  performs, and about which of those operations can throw.

In other words, the description of the sentry constructor has been
declared to be *clear* and *precise*. Since the description is
precise, and it does not say that the sentry::sentry() catches
exceptions, I assume this means that it should not catch any
exceptions.

The problem is that sentry::sentry() performs input (calls
rdbuf()->sgetc() and/or rdbuf()->sbumpc()) and operator>> is
supposed to catch those exceptions - which means it must catch all
exceptions thrown by sentry::sentry(), including those thrown by
setstate(). I don't think it would make sense to treat exceptions
thrown by setstate() differently based on whether setstate() was
called directly by operator>> or indirectly through sentry::sentry(),
so operator>> should catch exceptions thrown from setstate().

However, if this is the intended meaning, then we have a potential
DR: The description of badbit in 27.4.2.1.3 is incomplete and the
words "or (exceptions() & failbit) != 0" need to be added.

Petur