public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-23 20:30 Martin Sebor
0 siblings, 0 replies; 8+ messages in thread
From: Martin Sebor @ 2003-03-23 20:30 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't
work
Date: Sun, 23 Mar 2003 13:18:57 -0700
Pétur Runólfsson wrote:
...
>
> Note the "during input". I read that as meaning that this refers only
> to exceptions thrown by the call to num_get::get(), not to exceptions
> thrown from other functions the extractors may call.
The general requirements on what causes exceptions to be caught
and rethrown are buried in 27.6.1.1, p1-4. According to the text
only calls to members of streambuf are supposed to be checked
for exceptions. But because it's not possible to distinguish
between an exception thrown by, say, a (virtual) member function
of ctype called from num_get::get() and one thrown by a (virtual)
streambuf member called (indirectly, via an istreambuf_iterator
member) from num_get::get(), the requirement cannot realistically
be taken to mean just exceptions thrown during a call to num_get
::get() and not, for instance, ctype::is() called by the istream
::sentry ctor. IMO, stream members should consistently catch all
exceptions from any functions they may call.
>
...
> The whole text about the meaning of exceptions() and the handling of
> exceptions thrown during calls to I/O functions seems rather messy.
> Perhaps someone more familiar with the standard cares to comment?
I agree that error handling in iostreams (and locale) in general
and exception handling in particular is less than perfect. I have
filed a number of issues(*) in an attempt to clean up this area
but I have a feeling there is more work to be done.
(*) A number of them aren't listed yet (they should be in Revision
25 of the issues list), but this one is
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#309
Regards
Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-26 2:56 Martin Sebor
0 siblings, 0 replies; 8+ messages in thread
From: Martin Sebor @ 2003-03-26 2:56 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: Martin Sebor <sebor@roguewave.com>
To: gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't
work
Date: Tue, 25 Mar 2003 19:29:23 -0700
Pétur Runólfsson wrote:
>
...
> Do you mean that "these called functions" in p4 only refers to
> rdbuf()->sbumpc() and rdbuf()->sgetc() and not setstate()?
Yes, that's how I read it.
>
> The part "as if the called function had returned a failure
> indication" implies that setstate is not included (after all, it
> doesn't return failure indications), but the part "If badbit is
> on in exceptions(), [...], otherwise it does not throw anything"
> implies that s >> x will only throw if
> (s.exceptions() & ios::badbit) != 0, so setstate should be
> included (but this contradicts the resolution to DR 64).
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.
>
...
>> > IMO, stream members should consistently catch all
>> > exceptions from any functions they may call.
>>I buy this :-)
>
>
> I agree, however I also think that exceptions() should be consistent
> with itself, that is, setting exceptions(foobit) should simply mean
> that whenever foobit is set in rdstate(), an exception is thrown.
I agree.
> 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?
>
...
> [1] Actually, the resolution talks about exceptions thrown "while
> extracting characters from sb" which seems rather silly as the
> function extracts characters from rdbuf() and inserts them into
> sb.
That looks like a typo in the resolution. I would expect the
function to behave as if the text read:
If the function inserts no characters, it calls setstate
(failbit), which may throw ios_base::failure (27.4.4.3).
If the function caught an exception thrown while inserting
characters into *sb then if failbit is on in exceptions()
(27.4.4.3), failbit is set in *this without throwing
ios_base::failure and the caught exception is rethrown;
otherwise the function calls setstate(failbit), which may
throw ios_base::failure (27.4.4.3).
Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-24 18:26 Pétur Runólfsson
0 siblings, 0 replies; 8+ messages in thread
From: Pétur Runólfsson @ 2003-03-24 18:26 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: <jlquinn@optonline.net>,
"Martin Sebor" <sebor@roguewave.com>
Cc: <gcc-gnats@gcc.gnu.org>,
<libstdc++@gcc.gnu.org>
Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
Date: Mon, 24 Mar 2003 18:21:12 -0000
I wrote:
> I agree, however I also think that exceptions() should be consistent
> with itself, that is, setting exceptions(foobit) should simply mean
> that whenever foobit is set in rdstate(), an exception is thrown.
> 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.
Just to clarify:
What I think that ios::exceptions() means (and what appears to have
been the intent, judging by some old USENET posts) is that this
should always work:
istream is(...);
is.exceptions(...);
...
try
{
is >> x;
assert((is.exceptions() & is.rdstate()) =3D=3D 0);
}
catch (...)
{
assert((is.exceptions() & is.rdstate()) !=3D 0);
}
Likewise for ostream and for unformatted I/O functions. Also, the
value of is.rdstate() at the end of this code should not depend on
the value of is.exceptions().
Regards,
Petur
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-24 11:09 Pétur Runólfsson
0 siblings, 0 replies; 8+ messages in thread
From: Pétur Runólfsson @ 2003-03-24 11:09 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: <jlquinn@optonline.net>,
"Martin Sebor" <sebor@roguewave.com>
Cc: <gcc-gnats@gcc.gnu.org>,
<libstdc++@gcc.gnu.org>
Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
Date: Mon, 24 Mar 2003 10:46:51 -0000
Jerry Quinn wrote:
> Martin Sebor writes:
> > P=E9tur Run=F3lfsson wrote:
> > ...
> > >=20
> > > Note the "during input". I read that as meaning that=20
> this refers only
> > > to exceptions thrown by the call to num_get::get(), not=20
> to exceptions
> > > thrown from other functions the extractors may call.
> > =20
> > The general requirements on what causes exceptions to be caught
> > and rethrown are buried in 27.6.1.1, p1-4. According to the text
> > only calls to members of streambuf are supposed to be checked
> > for exceptions.
Do you mean that "these called functions" in p4 only refers to
rdbuf()->sbumpc() and rdbuf()->sgetc() and not setstate()?
The part "as if the called function had returned a failure
indication" implies that setstate is not included (after all, it
doesn't return failure indications), but the part "If badbit is
on in exceptions(), [...], otherwise it does not throw anything"
implies that s >> x will only throw if
(s.exceptions() & ios::badbit) !=3D 0, so setstate should be
included (but this contradicts the resolution to DR 64).
> > But because it's not possible to distinguish
> > between an exception thrown by, say, a (virtual) member function
> > of ctype called from num_get::get() and one thrown by a (virtual)
> > streambuf member called (indirectly, via an istreambuf_iterator
> > member) from num_get::get(), the requirement cannot realistically
> > be taken to mean just exceptions thrown during a call to num_get
> > ::get() and not, for instance, ctype::is() called by the istream
> > ::sentry ctor.
I agree. It seems reasonable to set badbit if say,
use_facet<ctype<CharT> >(getloc()) fails (since this makes the stream
unreadable, i.e. bad), but neither 27.6.1.1 nor 27.6.1.2.1 says
anything about this one way or the other if we take "these called
functions" and "during input" to mean only rdbuf->sbumpc() and
rdbuf()->sgetc().
> > IMO, stream members should consistently catch all
> > exceptions from any functions they may call.
> I buy this :-)
I agree, however I also think that exceptions() should be consistent
with itself, that is, setting exceptions(foobit) should simply mean
that whenever foobit is set in rdstate(), an exception is thrown.
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.
> Given that we catch all the exceptions,
IMHO this is never stated unambiguously in the standard.
> when do we
> rethrow? The original text says rethrow if badbit is set in the
> exception mask. DR64 says to rethrow if failbit is set and the
> exception mask has failbit set. So, does it make sense to change
No. DR 64 only refers to
basic_istream<C, T>::operator>>(basic_streambuf<C, T>* sb). It only
states that if operations on sb [1] throw then failbit should be set
in rdstate(), and if (exceptions() & failbit) !=3D 0, the exception is
rethrown. It does not override the requirements on formatted input
functions, so exceptions thrown by operations on rdbuf() should
cause badbit to be set, and only be rethrown if
(exceptions() & badbit) !=3D 0. The reason I brought up this DR is
that the resolution states that exceptions thrown by
setstate(failbit) should not be caught.
Petur
[1] Actually, the resolution talks about exceptions thrown "while
extracting characters from sb" which seems rather silly as the
function extracts characters from rdbuf() and inserts them into
sb.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-23 19:26 Pétur Runólfsson
0 siblings, 0 replies; 8+ messages in thread
From: Pétur Runólfsson @ 2003-03-23 19:26 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Jerry Quinn" <jlquinn@optonline.net>,
<gcc-gnats@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>,
<gcc-prs@gcc.gnu.org>,
<libstdc++@gcc.gnu.org>
Cc:
Subject: RE: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
Date: Sun, 23 Mar 2003 19:13:24 -0000
Jerry Quinn wrote:
> I'm a bit confused by this bug. What should the behavior be=20
> here? To my
> simple reading of the standard, it seems that the code is=20
> operating correctly.
>=20
> The test case is designed to throw if failbit is set. =20
> Failbit does get set,
> which causes the exception to be thrown. However, it is caught in the
> exception handler and not rethrown.
>=20
> 27.6.1.2.1 says that the exception is rethrown if badbit is set in the
> exception mask (and badbit is set), otherwise not. This=20
> makes it sound like
> the _only_ way to get an exception from the formatted input=20
> functions is to
> set badbit in the exception mask.
This is the relevant quote:
27.6.1.2.1 - Common requirements [lib.istream.formatted.reqmts]
-1- [...] If an exception is thrown *during input* then ios::badbit is
turned on in *this's error state.=20
If (exception() & badbit) !=3D 0 then the exception is rethrown. In =
any
case, the formatted input function destroys the sentry object. If no
exception has been thrown, it returns *this.
Note the "during input". I read that as meaning that this refers only
to exceptions thrown by the call to num_get::get(), not to exceptions
thrown from other functions the extractors may call.
IMHO the resolution to DR 64 is in support of this reading, as well as
the description of badbit in 27.4.2.1.3.
Also, the function exceptions(iostate) is rather silly if only badbit
is supposed to cause exceptions to be thrown.
The whole text about the meaning of exceptions() and the handling of
exceptions thrown during calls to I/O functions seems rather messy.
Perhaps someone more familiar with the standard cares to comment?
Petur
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-23 6:56 Jerry Quinn
0 siblings, 0 replies; 8+ messages in thread
From: Jerry Quinn @ 2003-03-23 6:56 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/10093; it has been noted by GNATS.
From: Jerry Quinn <jlquinn@optonline.net>
To: gcc-gnats@gcc.gnu.org, peturr02@ru.is, gcc-bugs@gcc.gnu.org,
gcc-prs@gcc.gnu.org, libstdc++@gcc.gnu.org
Cc:
Subject: Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't
work
Date: Sun, 23 Mar 2003 01:50:11 -0500
I'm a bit confused by this bug. What should the behavior be here? To my
simple reading of the standard, it seems that the code is operating correctly.
The test case is designed to throw if failbit is set. Failbit does get set,
which causes the exception to be thrown. However, it is caught in the
exception handler and not rethrown.
27.6.1.2.1 says that the exception is rethrown if badbit is set in the
exception mask (and badbit is set), otherwise not. This makes it sound like
the _only_ way to get an exception from the formatted input functions is to
set badbit in the exception mask.
Petur, can you explain what I'm missing?
Thanks
Jerry Quinn
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-22 15:22 paolo
0 siblings, 0 replies; 8+ messages in thread
From: paolo @ 2003-03-22 15:22 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jlquinn, nobody, peturr02
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
Synopsis: Regression: Setting failbit in exceptions doesn't work
Responsible-Changed-From-To: unassigned->jlquinn
Responsible-Changed-By: paolo
Responsible-Changed-When: Sat Mar 22 15:22:25 2003
Responsible-Changed-Why:
Jerry, can you please have a look? According to Pétur, the
problem may have to do with your fix for 9561.
Thanks, Paolo.
State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Sat Mar 22 15:22:25 2003
State-Changed-Why:
Confirmed.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10093
^ permalink raw reply [flat|nested] 8+ messages in thread
* libstdc++/10093: Regression: Setting failbit in exceptions doesn't work
@ 2003-03-15 10:36 peturr02
0 siblings, 0 replies; 8+ messages in thread
From: peturr02 @ 2003-03-15 10:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 10093
>Category: libstdc++
>Synopsis: Regression: Setting failbit in exceptions doesn't work
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Mar 15 10:36:01 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: peturr02@ru.is
>Release: gcc version 3.3 20030310 (prerelease)
>Organization:
>Environment:
Red Hat Linux 8.0
>Description:
Setting ios_base::failbit in basic_ios::exceptions does not cause basic_istream::operator>>(int&) to throw an exception.
This appears to have been caused by the recent patch for PR libstdc++/9561.
>How-To-Repeat:
See attachment.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="exceptionsbug2.cc"
Content-Disposition: inline; filename="exceptionsbug2.cc"
#include <sstream>
#undef NDEBUG
#include <cassert>
int main()
{
using namespace std;
istringstream stream("whatever");
stream.exceptions(ios::failbit);
try
{
int i;
stream >> i;
assert(false);
}
catch (ios::failure&)
{
}
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-03-26 2:36 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-23 20:30 libstdc++/10093: Regression: Setting failbit in exceptions doesn't work Martin Sebor
-- strict thread matches above, loose matches on Subject: below --
2003-03-26 2:56 Martin Sebor
2003-03-24 18:26 Pétur Runólfsson
2003-03-24 11:09 Pétur Runólfsson
2003-03-23 19:26 Pétur Runólfsson
2003-03-23 6:56 Jerry Quinn
2003-03-22 15:22 paolo
2003-03-15 10:36 peturr02
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).