public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sebor at roguewave dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work Date: Thu, 24 Jul 2003 22:34:00 -0000 [thread overview] Message-ID: <20030724223457.17071.qmail@sources.redhat.com> (raw) In-Reply-To: <20030315103601.10093.peturr02@ru.is> 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 sebor at roguewave dot com 2003-07-24 22:34 ------- Subject: Re: Regression: Setting failbit in exceptions doesn't work peturr02 at ru dot is wrote: ... > > 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?) Hmm, dunno. I sent an email to have them 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(). Agreed. > > The implementation of operator>> you described seems to > achieve exactly this. Yes. Our implementation tries to follow 1) and 2) above. > > 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. Again, I don't think the intent of the original design was anything other than your 1) and 2) above, despite the status of 399 or 309. > > >>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(). The intent as I understand it from the email discussions that took place years ago on the reflector, was to accommodate, at least to some extent, classic iostreams, that didn't throw exceptions and didn't expect any functions called from the iostream members to do so, either. The text in iostreams is probably slightly out of sync with locale, which came later. My guess is that whoever wrote it did not anticipate any virtual functions other than members of streambuf to be called from iostream members. The only sane and consistent thing to do, IMHO, is to have iostreams behave according to your 1) and 2) above. > > (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.) I think one just needs to take the standard with a big grain of salt when it comes to error handling in iostreams. Martin
next prev parent reply other threads:[~2003-07-24 22:34 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20030315103601.10093.peturr02@ru.is> 2003-07-01 10:08 ` peturr02 at ru dot is 2003-07-02 1:02 ` sebor at roguewave dot com 2003-07-24 15:47 ` peturr02 at ru dot is 2003-07-24 17:08 ` sebor at roguewave dot com 2003-07-24 20:43 ` peturr02 at ru dot is 2003-07-24 22:34 ` sebor at roguewave dot com [this message] 2003-09-03 8:17 ` peturr02 at ru dot is 2003-09-03 16:25 ` [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] " pinskia at gcc dot gnu dot org 2003-10-16 2:53 ` mmitchel at gcc dot gnu dot org 2003-10-24 7:59 ` bkoz at gcc dot gnu dot org 2003-11-27 8:14 ` cvs-commit at gcc dot gnu dot org 2003-11-27 9:05 ` pinskia at gcc dot gnu dot org 2003-12-04 3:09 ` cvs-commit at gcc dot gnu dot org 2003-12-04 3:11 ` cvs-commit at gcc dot gnu dot org 2003-12-04 8:21 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030724223457.17071.qmail@sources.redhat.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).