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

["Pétur Runólfsson" <peturr02@ru.is>]

The following reply was made to PR libstdc++/10093; it has been noted by GNATS.

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Jerry Quinn" <jlquinn@optonline.net>,
	<gcc-gnats@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<gcc-prs@gcc.gnu.org>,
	<libstdc++@gcc.gnu.org>
Cc:  
Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
Date: Sun, 23 Mar 2003 19:13:24 -0000

 Jerry Quinn wrote:
 > I'm a bit confused by this bug.  What should the behavior be=20
 > here?  To my
 > simple reading of the standard, it seems that the code is=20
 > operating correctly.
 >=20
 > The test case is designed to throw if failbit is set. =20
 > Failbit does get set,
 > which causes the exception to be thrown.  However, it is caught in the
 > exception handler and not rethrown.
 >=20
 > 27.6.1.2.1 says that the exception is rethrown if badbit is set in the
 > exception mask (and badbit is set), otherwise not.  This=20
 > makes it sound like
 > the _only_ way to get an exception from the formatted input=20
 > functions is to
 > set badbit in the exception mask.
 
 This is the relevant quote:
 
   27.6.1.2.1 - Common requirements [lib.istream.formatted.reqmts]
   -1- [...] If an exception is thrown *during input* then ios::badbit is
   turned on in *this's error state.=20
 
   If (exception() & badbit) !=3D 0 then the exception is rethrown. In =
 any
   case, the formatted input function destroys the sentry object. If no
   exception has been thrown, it returns *this.
 
 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.
 
 IMHO the resolution to DR 64 is in support of this reading, as well as
 the description of badbit in 27.4.2.1.3.
 
 Also, the function exceptions(iostate) is rather silly if only badbit
 is supposed to cause exceptions to be thrown.
 
 The whole text about the meaning of exceptions() and the handling of
 exceptions thrown during calls to I/O functions seems rather messy.
 Perhaps someone more familiar with the standard cares to comment?
 
 Petur