From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10663 invoked by alias); 24 Jul 2003 15:47:30 -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 10636 invoked by uid 48); 24 Jul 2003 15:47:25 -0000 Date: Thu, 24 Jul 2003 15:47:00 -0000 Message-ID: <20030724154725.10633.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/msg02895.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-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