From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28670 invoked by alias); 24 Jul 2003 20:43:46 -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 28643 invoked by uid 48); 24 Jul 2003 20:43:45 -0000 Date: Thu, 24 Jul 2003 20:43:00 -0000 Message-ID: <20030724204345.28642.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/msg02930.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 20:43 ------- Martin Sebor wrote: > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#309 That's not the latest version; revision 26 (post-oxford) is here: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1480.html (Why haven't the links been updated?) The only semantics for exceptions() that make any real amount of sense are that after a call to an (un)formatted input/output operation R on a [io]stream s and object x: s R x; 1) If (s.rdstate() == 0) before the call, an exception is thrown if and only if after the call (s.rdstate() & s.exceptions()) != 0; 2) The value of s.rdstate() after the call does not depend on the value of s.exceptions(). The implementation of operator>> you described seems to achieve exactly this. Unfortunately the description of basic_ios::exceptions() gives no such guarantees, nor any other hint whatsoever about what the intent of exceptions() was. Even worse, the rationale for closing DR 399 as NAD indicates that property 1) isn't supposed to hold. > I don't think this could ever pass. The intent of badbit is > to indicate some unrecoverable error in the stream buffer. > Setting it as a result of failbit being set in both state > and exceptions would defeat the purpose of the bit. I agree. If property 2) doesn't hold, badbit is meaningless if either failbit or eofbit is set in exceptions(). Perhaps I am reading to much into the words "if an exception is thrown during input" in 27.6.1.2.1 and the intent is not to catch exceptions thrown during the sentry constructor, whether by use_facet, ctype::is or rdbuf()->underflow(). (Or perhaps the "no clarification needed" part of the rationale for DR 309 simply means that 27.6.1.2.1 already requires sentry::sentry() to catch exceptions; but if this is accepted one might equally argue that 27.6.1.2.1 requires num_get::get to catch exceptions. I don't think this can be intended.) Petur