From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11961 invoked by alias); 1 Jul 2003 10:08:29 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11939 invoked by uid 48); 1 Jul 2003 10:08:28 -0000 Date: Tue, 01 Jul 2003 10:08:00 -0000 Message-ID: <20030701100828.11936.qmail@sources.redhat.com> From: "peturr02 at ru dot is" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030315103601.10093.peturr02@ru.is> References: <20030315103601.10093.peturr02@ru.is> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work X-Bugzilla-Reason: CC X-SW-Source: 2003-07/txt/msg00025.txt.bz2 List-Id: 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& get(basic_streambuf& 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