public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [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 ` (13 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: peturr02 at ru dot is @ 2003-07-01 10:08 UTC (permalink / raw) To: gcc-bugs 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<charT,traits>& get(basic_streambuf<char_type,traits>& 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> 2003-07-01 10:08 ` [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work 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 ` (12 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: sebor at roguewave dot com @ 2003-07-02 1:02 UTC (permalink / raw) To: gcc-bugs 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-02 01:02 ------- Subject: Re: Regression: Setting failbit in exceptions doesn't work peturr02 at ru dot is wrote: ... > 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. My feeling is that if setstate() should end up throwing an exception some exception should always propagate out of the calling function. > ... > basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& 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(). I don't think that's the intended interpretation but I agree that it's a possible one. I would like to believe that the intent here was only to swallow exceptions thrown from calls on sb (although I don't like that either). > 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(). Right. I don't think swallowing the exception is correct. IMO, if exceptions are on, the function should rethrow the exception no matter where it comes from. The reason for exceptions in iostreams being optional is to provide backward compatibility with classic iostreams. Once they're on there's no reason to swallow them. The more interesting question, IMO, is what bit to set if one of the virtual calls on sb throws an exception. Should badbit be set? I would be inclined to say no since the purpose of the bit is to indicate some unrecoverable error in the stream object's streambuf, but not necessarily such an error in the argument. The stream itself might be perfectly fine after the exception. My approach would be to set failbit in this case (which is what our implementation does). If failbit is also set in exceptions, the original exception is rethrown. This is done without causing badbit to be set. Martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> 2003-07-01 10:08 ` [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work 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 ` (11 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: peturr02 at ru dot is @ 2003-07-24 15:47 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (2 preceding siblings ...) 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 ` (10 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: sebor at roguewave dot com @ 2003-07-24 17:08 UTC (permalink / raw) To: gcc-bugs 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 17:08 ------- Subject: Re: Regression: Setting failbit in exceptions doesn't work peturr02 at ru dot is wrote: > ------- 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. What DR is this again? I don't see this in the still open issue 309: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#309 > > 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. 309 proposes that the sentry ctor set badbit if it catches an exception during input, and that the caught exception be rethrown when (badbit & exceptions()) is non-zero. > > The problem is that sentry::sentry() performs input (calls > rdbuf()->sgetc() and/or rdbuf()->sbumpc()) and operator>> is > supposed to catch those exceptions That's not my understanding. Here's how I would implement operator>>() (which is also what our library does, even though the code might look different): operator>>(int &x) { sentry guard (*this); if (guard) { iostate err; try { use_facet<num_get<charT> >(getloc ()) .get (..., *this, err, x); } catch (...) { bool rethrow; try { setstate (badbit); rethrow = false; } catch (...) { rethrow = true; } if (rethrow) throw; } if (err) setstate (err); } } > - 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(). That's why sentry must catch exceptions, and that's also why you can't implement the function above as operator>>(int &x) { try { sentry guard (*this); ... } catch (...) { bool rethrow; try { setstate (badbit); ... Because such an implementation would end up setting badbit if sentry threw failbit. I'm sure you agree that's not what should happen. > > 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. 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. If there is a defect in there somewhere (I don't doubt there is), it's in the imprecise wording possibly even muddied by a number of fixes that went into the TC, not in the intent. Martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (3 preceding siblings ...) 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 ` (9 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: peturr02 at ru dot is @ 2003-07-24 20:43 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (4 preceding siblings ...) 2003-07-24 20:43 ` peturr02 at ru dot is @ 2003-07-24 22:34 ` sebor at roguewave dot com 2003-09-03 8:17 ` peturr02 at ru dot is ` (8 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: sebor at roguewave dot com @ 2003-07-24 22:34 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (5 preceding siblings ...) 2003-07-24 22:34 ` sebor at roguewave dot com @ 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 ` (7 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: peturr02 at ru dot is @ 2003-09-03 8:17 UTC (permalink / raw) To: gcc-bugs 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-09-03 08:17 ------- I don't know how I managed to miss this: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#61 This means that exceptions thrown by setstate() should not be caught. So this bug is real, and is a regression. This still leaves open what to do in sentry::sentry(), but that's not really relevant to this bug, and is the subject of another DR: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#309 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (6 preceding siblings ...) 2003-09-03 8:17 ` peturr02 at ru dot is @ 2003-09-03 16:25 ` pinskia at gcc dot gnu dot org 2003-10-16 2:53 ` mmitchel at gcc dot gnu dot org ` (6 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-09-03 16:25 UTC (permalink / raw) To: gcc-bugs 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 pinskia at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical Summary|Regression: Setting failbit |[3.3/3.4 Regression] [L DR |in exceptions doesn't work |61] Setting failbit in | |exceptions doesn't work Target Milestone|--- |3.3.2 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (7 preceding siblings ...) 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 ` (5 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: mmitchel at gcc dot gnu dot org @ 2003-10-16 2:53 UTC (permalink / raw) To: gcc-bugs 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 mmitchel at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.3.2 |3.3.3 ------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-10-16 02:53 ------- Postponed until GCC 3.3.3. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (8 preceding siblings ...) 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 ` (4 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: bkoz at gcc dot gnu dot org @ 2003-10-24 7:59 UTC (permalink / raw) To: gcc-bugs 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 bkoz at gcc dot gnu dot org 2003-10-24 07:41 ------- I think something like this will work, but will have to be propagated throughout the istream/ostream functions. Index: include/bits/istream.tcc =================================================================== RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/istream.tcc,v retrieving revision 1.52 diff -c -p -r1.52 istream.tcc *** include/bits/istream.tcc 12 Oct 2003 10:12:08 -0000 1.52 --- include/bits/istream.tcc 24 Oct 2003 07:39:25 -0000 *************** namespace std *** 60,69 **** while (!traits_type::eq_int_type(__c, __eof) && __ct.is(ctype_base::space, traits_type::to_char_type(__c))) ! __c = __sb->snextc(); // _GLIBCXX_RESOLVE_LIB_DEFECTS ! // 195. Should basic_istream::sentry's constructor ever set eofbit? if (traits_type::eq_int_type(__c, __eof)) __in.setstate(ios_base::eofbit); } --- 60,70 ---- while (!traits_type::eq_int_type(__c, __eof) && __ct.is(ctype_base::space, traits_type::to_char_type(__c))) ! __c = __sb->snextc(); // _GLIBCXX_RESOLVE_LIB_DEFECTS ! // 195. Should basic_istream::sentry's constructor ever ! // set eofbit? if (traits_type::eq_int_type(__c, __eof)) __in.setstate(ios_base::eofbit); } *************** namespace std *** 113,124 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 114,124 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 128,133 **** --- 128,134 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 140,149 **** sentry __cerb(*this, false); if (__cerb) { try { long __l; - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __l); // _GLIBCXX_RESOLVE_LIB_DEFECTS --- 141,150 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { long __l; const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __l); // _GLIBCXX_RESOLVE_LIB_DEFECTS *************** namespace std *** 154,160 **** __n = __l; else __err |= ios_base::failbit; - this->setstate(__err); } catch(...) { --- 155,160 ---- *************** namespace std *** 164,169 **** --- 164,170 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 176,187 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 177,187 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 191,196 **** --- 191,197 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 203,212 **** sentry __cerb(*this, false); if (__cerb) { try { long __l; - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __l); // _GLIBCXX_RESOLVE_LIB_DEFECTS --- 204,213 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { long __l; const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __l); // _GLIBCXX_RESOLVE_LIB_DEFECTS *************** namespace std *** 217,223 **** __n = __l; else __err |= ios_base::failbit; - this->setstate(__err); } catch(...) { --- 218,223 ---- *************** namespace std *** 227,232 **** --- 227,233 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 239,250 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 240,250 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 254,259 **** --- 254,260 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 266,277 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 267,277 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 281,286 **** --- 281,287 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 293,304 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 294,304 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 308,313 **** --- 308,314 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 321,332 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 322,332 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 336,341 **** --- 336,342 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 348,359 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 349,359 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 363,368 **** --- 363,369 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 376,387 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 377,387 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 391,396 **** --- 391,397 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 403,414 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 404,414 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 418,423 **** --- 418,424 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 430,441 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 431,441 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 445,450 **** --- 445,451 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } *************** namespace std *** 457,468 **** sentry __cerb(*this, false); if (__cerb) { try { - ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); - this->setstate(__err); } catch(...) { --- 458,468 ---- sentry __cerb(*this, false); if (__cerb) { + ios_base::iostate __err = ios_base::iostate(ios_base::goodbit); try { const __num_get_type& __ng = __check_facet(this->_M_num_get); __ng.get(*this, 0, *this, __err, __n); } catch(...) { *************** namespace std *** 472,477 **** --- 472,478 ---- if ((this->exceptions() & ios_base::badbit) != 0) __throw_exception_again; } + this->setstate(__err); } return *this; } ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (9 preceding siblings ...) 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 ` (3 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: cvs-commit at gcc dot gnu dot org @ 2003-11-27 8:14 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From cvs-commit at gcc dot gnu dot org 2003-11-27 08:14 ------- Subject: Bug 10093 CVSROOT: /cvs/gcc Module name: gcc Changes by: bkoz@gcc.gnu.org 2003-11-27 08:14:25 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: basic_ios.h basic_ios.tcc fstream.tcc istream.tcc locale_facets.tcc ostream.tcc streambuf.tcc libstdc++-v3/testsuite: testsuite_io.h libstdc++-v3/testsuite/27_io/basic_istream/exceptions/char: 9561.cc Added files: libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char: exceptions_badbit_throw.cc exceptions_failbit.cc exceptions_failbit_throw.cc libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char: error_failbit.cc exceptions_badbit_throw.cc exceptions_failbit_throw.cc exceptions_null.cc libstdc++-v3/testsuite/27_io/basic_istream/seekg/char: exceptions_badbit_throw.cc libstdc++-v3/testsuite/27_io/basic_istream/tellg/char: exceptions_badbit_throw.cc libstdc++-v3/testsuite/27_io/basic_ostream/flush/char: exceptions_badbit_throw.cc libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char: exceptions_badbit_throw.cc exceptions_failbit_throw.cc libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char: error_failbit.cc exceptions_badbit_throw.cc exceptions_failbit_throw.cc exceptions_null.cc libstdc++-v3/testsuite/27_io/basic_ostream/seekp/char: exceptions_badbit_throw.cc libstdc++-v3/testsuite/27_io/basic_ostream/tellp/char: exceptions_badbit_throw.cc Log message: 2003-11-26 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/9371 PR libstdc++/9546 PR libstdc++/10093 PR libstdc++/10095 * include/bits/basic_ios.h (basic_ios::setstate): Elide if goodbit. (basic_ios::_M_setstate): Consolidate common error handling code. * include/bits/basic_ios.tcc: Tweak. * include/bits/fstream.tcc: Tweak. * include/bits/istream.tcc: Use _M_setstate for common exception handling. Move setstate calls after catch. (basic_istream::tellg): Check for exceptions thrown by streambuf virtual functions. (basic_istream::seekg): Same. * include/bits/ostream.tcc: Same, but for ostream. (basic_ostream::flush): Check for exceptions thrown by streambuf virtual functions. (basic_istream::tellp): Same. (basic_istream::seekp): Same. * include/bits/locale_facets.tcc: Tweak. * include/bits/streambuf.tcc: Tweak. (__copy_streambufs): Propagate exceptions. * testsuite/testsuite_io.h (fail_streambuf): New. (fail_num_get): New. (fail_num_put): New. (facet_error): New. (underflow_error): New. (overflow_error): New. (positioning_error): New. * testsuite/27_io/basic_istream/exceptions/char/9561.cc: Tweak. * testsuite/27_io/basic_istream/extractors_arithmetic/char/ exceptions_badbit_throw.cc, exceptions_failbit.cc, exceptions_failbit_throw.cc: New. * testsuite/27_io/basic_istream/extractors_other/char/ error_failbit.cc, exceptions_badbit_throw.cc, exceptions_failbit_throw.cc, exceptions_null.cc: New. * testsuite/27_io/basic_istream/seekg/char/exceptions_badbit_throw.cc: New. * testsuite/27_io/basic_istream/tellg/char/exceptions_badbit_throw.cc: New. * testsuite/27_io/basic_ostream/flush/char/exceptions_badbit_throw.cc: New. * testsuite/27_io/basic_ostream/inserters_arithmetic/char/ exceptions_badbit_throw.cc, exceptions_failbit_throw.cc: New. * testsuite/27_io/basic_ostream/inserters_other/char/ error_failbit.cc, exceptions_badbit_throw.cc, exceptions_failbit_throw.cc, exceptions_null.cc: New. * testsuite/27_io/basic_ostream/seekp/char/exceptions_badbit_throw.cc: New. * testsuite/27_io/basic_ostream/tellp/char/exceptions_badbit_throw.cc: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2111&r2=1.2112 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_ios.h.diff?cvsroot=gcc&r1=1.25&r2=1.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_ios.tcc.diff?cvsroot=gcc&r1=1.27&r2=1.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/fstream.tcc.diff?cvsroot=gcc&r1=1.109&r2=1.110 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/istream.tcc.diff?cvsroot=gcc&r1=1.57&r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/locale_facets.tcc.diff?cvsroot=gcc&r1=1.147&r2=1.148 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/ostream.tcc.diff?cvsroot=gcc&r1=1.47&r2=1.48 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/streambuf.tcc.diff?cvsroot=gcc&r1=1.45&r2=1.46 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/testsuite_io.h.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/exceptions/char/9561.cc.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/error_failbit.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_failbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/seekg/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_istream/tellg/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/flush/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/exceptions_failbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/error_failbit.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_failbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/seekp/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_ostream/tellp/char/exceptions_badbit_throw.cc.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (10 preceding siblings ...) 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 ` (2 subsequent siblings) 14 siblings, 0 replies; 15+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-11-27 9:05 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2003-11-27 09:05 ------- Fixed for 3.4 but will be fix also for 3.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (11 preceding siblings ...) 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 14 siblings, 0 replies; 15+ messages in thread From: cvs-commit at gcc dot gnu dot org @ 2003-12-04 3:09 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From cvs-commit at gcc dot gnu dot org 2003-12-04 03:09 ------- Subject: Bug 10093 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: bkoz@gcc.gnu.org 2003-12-04 03:09:44 Modified files: libstdc++-v3/include/bits: basic_ios.h fstream.tcc istream.tcc ostream.tcc streambuf.tcc Log message: 2003-12-03 Benjamin Kosnik <bkoz@redhat.com> * include/bits/basic_ios.h (basic_ios::setstate): Revert. * include/bits/istream.tcc: Only call setstate if __err != goodbit. * include/bits/ostream.tcc: Same. * testsuite/27_io/basic_ios/exceptions/char/2.cc: New. 2003-12-03 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/9371 PR libstdc++/9546 PR libstdc++/10093 PR libstdc++/10095 * include/bits/basic_ios.h (basic_ios::setstate): Elide if goodbit. (basic_ios::_M_setstate): Consolidate common error handling code. * include/bits/basic_ios.tcc: Tweak. * include/bits/fstream.tcc: Tweak. * include/bits/istream.tcc: Use _M_setstate for common exception handling. Move setstate calls after catch. (basic_istream::tellg): Check for exceptions thrown by streambuf virtual functions. (basic_istream::seekg): Same. * include/bits/ostream.tcc: Same, but for ostream. (basic_ostream::flush): Check for exceptions thrown by streambuf virtual functions. (basic_istream::tellp): Same. (basic_istream::seekp): Same. * include/bits/locale_facets.tcc: Tweak. * include/bits/streambuf.tcc: Tweak. (__copy_streambufs): Propagate exceptions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/basic_ios.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.14.2.6&r2=1.14.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/fstream.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.42.2.12&r2=1.42.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/istream.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.36.4.8&r2=1.36.4.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/ostream.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.31.14.7&r2=1.31.14.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/streambuf.tcc.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.21.2.5&r2=1.21.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (12 preceding siblings ...) 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 14 siblings, 0 replies; 15+ messages in thread From: cvs-commit at gcc dot gnu dot org @ 2003-12-04 3:11 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From cvs-commit at gcc dot gnu dot org 2003-12-04 03:11 ------- Subject: Bug 10093 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: bkoz@gcc.gnu.org 2003-12-04 03:10:55 Modified files: libstdc++-v3 : ChangeLog Log message: 2003-12-03 Benjamin Kosnik <bkoz@redhat.com> * include/bits/basic_ios.h (basic_ios::setstate): Revert. * include/bits/istream.tcc: Only call setstate if __err != goodbit. * include/bits/ostream.tcc: Same. * testsuite/27_io/basic_ios/exceptions/char/2.cc: New. 2003-12-03 Benjamin Kosnik <bkoz@redhat.com> PR libstdc++/9371 PR libstdc++/9546 PR libstdc++/10093 PR libstdc++/10095 * include/bits/basic_ios.h (basic_ios::setstate): Elide if goodbit. (basic_ios::_M_setstate): Consolidate common error handling code. * include/bits/basic_ios.tcc: Tweak. * include/bits/fstream.tcc: Tweak. * include/bits/istream.tcc: Use _M_setstate for common exception handling. Move setstate calls after catch. (basic_istream::tellg): Check for exceptions thrown by streambuf virtual functions. (basic_istream::seekg): Same. * include/bits/ostream.tcc: Same, but for ostream. (basic_ostream::flush): Check for exceptions thrown by streambuf virtual functions. (basic_istream::tellp): Same. (basic_istream::seekp): Same. * include/bits/locale_facets.tcc: Tweak. * include/bits/streambuf.tcc: Tweak. (__copy_streambufs): Propagate exceptions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.1464.2.156&r2=1.1464.2.157 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093 ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug libstdc++/10093] [3.3/3.4 Regression] [L DR 61] Setting failbit in exceptions doesn't work [not found] <20030315103601.10093.peturr02@ru.is> ` (13 preceding siblings ...) 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 14 siblings, 0 replies; 15+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-12-04 8:21 UTC (permalink / raw) To: gcc-bugs ------- Additional Comments From pinskia at gcc dot gnu dot org 2003-12-04 08:21 ------- Fixed for 3.3.3. -- What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10093 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2003-12-04 8:21 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20030315103601.10093.peturr02@ru.is> 2003-07-01 10:08 ` [Bug libstdc++/10093] Regression: Setting failbit in exceptions doesn't work 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 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
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).