From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10720 invoked by alias); 24 Mar 2003 10:56:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 10706 invoked by uid 71); 24 Mar 2003 10:56:01 -0000 Date: Mon, 24 Mar 2003 11:09:00 -0000 Message-ID: <20030324105601.10705.qmail@sources.redhat.com> To: jlquinn@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Reply-To: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= X-SW-Source: 2003-03/txt/msg01581.txt.bz2 List-Id: The following reply was made to PR libstdc++/10093; it has been noted by GNATS. From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= To: , "Martin Sebor" Cc: , Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Date: Mon, 24 Mar 2003 10:46:51 -0000 Jerry Quinn wrote: > Martin Sebor writes: > > P=E9tur Run=F3lfsson wrote: > > ... > > >=20 > > > Note the "during input". I read that as meaning that=20 > this refers only > > > to exceptions thrown by the call to num_get::get(), not=20 > to exceptions > > > thrown from other functions the extractors may call. > > =20 > > 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) !=3D 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 >(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::operator>>(basic_streambuf* sb). It only states that if operations on sb [1] throw then failbit should be set in rdstate(), and if (exceptions() & failbit) !=3D 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) !=3D 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.