This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [basic-improvements] try/finally support for c/c++ - more tests


What you're asking for is that we have .eh_frame data, but that
we go look somewhere else when it comes time to decide if the
frame wants to handle exceptions.  This look-aside will have to
happen for each and every call frame, because we don't know which
frames are written in C and which aren't.
Couldn't it get a bit in its frame info to say whether or not it calls
pthread_cleanup_push?  That would make the check pretty cheap.  (I'm
not nearly as familiar as you with the format of that data; it might
well be that there's no place to put that bit.)

It's not like we're even breaking new ground on the language front.
Microsoft has supported try/finally in their C compiler for years.
Yes -- I wrote a pile of code that used it heavily. :-)

It has somewhat fancy semantics.  For example, you can catch
floating-point exceptions this way and other things that would be
signals in UNIX.  They have a "__leave" keyword; they have exception
handling (as well as cleanups) and they have ways to say whether you
keep unwinding, or stop where you are, when you hit the handler.

The aysnchronous exception aspect of their stuff is particularly
interesting.

It's partly because of Microsoft's stuff that I'm so nervous about
this feature.  Their semantics are not always what people expect, but
ours probably won't match theirs, and the next thing that will happen
will be that people will want to port "structured exception-handling"
code to GCC, and then we'll be in trouble.

I don't really comprehend the resistance to adding try/finally to C.
I never would have guessed that it would have been greeted with
anything but "hey that's cool".
You won't make that mistake again. :-)

We ought to be talking about new language features before we implement
them, so we can have the arguments up front.

I apologize to Aldy too -- the patches are technically sound, and the
goal of improving interactions between threads and C++ is a good one.
I appreciate the effort, and apologize if I've come across otherwise.

If you continue to be rock solid dead-set against this extension,
I guess I'll honor that and think of something else (probably with
something akin to longjmp_unwind).  That won't happen until I get
back from vacation late next week though.
I promise not to be a complete jerk. :-)

If everyone else wants to do this, I'll go along.

I would prefer longjmp_unwind; that's something we're supposed to
have anyhow, and it would be very useful in making existing C
libraries play more nicely with C++, so implementing that would be
a definite win.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]