This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: catch(...) and forced unwind
- From: Nathan Myers <ncm at cantrip dot org>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, gcc at gcc dot gnu dot org,rth at redhat dot com, mark at codesourcery dot com, drepper at redhat dot com,jakub at redhat dot com, dave at boost-consulting dot com, wekempf at cox dot net,fjh at cs dot mu dot oz dot au
- Date: Sat, 13 Dec 2003 00:28:40 -0800
- Subject: Re: catch(...) and forced unwind
- References: <xypwu91ofvf.fsf@miranda.boston.redhat.com> <20031212183754.13f4864b.bkoz@redhat.com> <xypad5xnr5s.fsf@miranda.boston.redhat.com> <20031213082241.GB2416@tofu.dreamhost.com>
[apologies to those seeing this twice -- mailing list trouble.]
On Sat, Dec 13, 2003 at 01:54:55AM -0500, Jason Merrill wrote:
> On Fri, 12 Dec 2003 18:37:54 -0600, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> >>I see three ways to fix this:
> >>
> >>1) automatically rethrow cancellation.
> >>2) explicitly rethrow cancellation--this would require some way to catch it
> >> specifically, but we really ought to have that anyway.
> >
> > What about
> >[...]
> > Ie, a __cancellation_handler that could be set to either rethrow,
> > continue, or abort?
>
> That seems plausible to me. I think that #2 would still be appropriate.
I suggested the distinct handler the last time this was discussed, and
the only comments on it were in agreement.
The point is that a program would be equipped to enforce
standard-conforming behavior. Just as now every C++ program that
uses cin and/or cout where performance matters starts with a call
"std::ios::sync_with_stdio(false);", every threaded program where
correctness matters would need to start with a call to fix the
cancellation handler, to behave in the way that well-written
libraries expect (and, therefore, require):
int main()
{
std::ios:sync_with_stdio(false);
# ifdef __GLIBC__ /* or some damn thing */
__gnu::set_cancellation(__gnu::__continue_cancellation);
# endif
...
It would stink, but would beat being unable to ship a program that has
documentable behavior. I would prefer to put that call in the static
init code for libstdc++. Of course the best approach would be to
leave exception semantics the hell alone; a patchable handler amounts
to damage control.
For an iostream exception handler, it would be fine for it to set
badbit and return, when a cancellation exception occurred. The next
cancellation exception wouldn't be in iostream code any more, because
the stream active when the cancellation occurred would be no longer
usable, and good code already handles finding badbit set.
Nathan Myers
ncm-nospam@cantrip.org