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

[Richard Henderson <rth at redhat dot com>]

On Thu, Nov 07, 2002 at 02:50:47PM -0800, Mark Mitchell wrote:
> When in C code, and you hit pthread_cleanup_push, call into the runtime
> passing the address of the start and end of the function you're in, and
> the frame pointer.  When unwinding, notice that you're in that PC range
> with that frame pointer, and run the cleanups that correspond to that
> range.  You're guaranteed to be getting these in the right order; as
> you unwind you'll always be pulling stuff off the front of the list.

I don't like the idea of registering such information at runtime.

It is a fact that to unwind through functions at all you have to 
compile with -fexceptions, otherwise the data in .eh_frame does
not exist.  And if .eh_frame does not exist, we don't have enough
information to find the next call frame.

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.  (And before you mention
the personality routine, you should note that any frame that does
not actually use EH constructs does not have a personality routine
and is thus not an indicator of language.)

Whereas if we add some sort of EH block primitive to C, the compiler
marks which regions need cleanups statically, in read-only data
structures, which are examined as normal during the unwind phase.

I think your option slows down EH for C++ and Java for no good reason.

---

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".  I apologize to Aldy for getting
him into this mess.

I really can't think of any solution to the thread cancelation 
problem that works as cleanly and correctly as try/finally.  Yes,
I can think of a few hacks that might could be made to work, but
that's all they are -- hacks.

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.
I can't imagine WG14 being so bull-headed as to define a similar
construct that is wildly incompatible with prior art.  Of course,
Microsoft fails to define their extension in anything even approaching
standards legaleese, but I think that we're on safe ground with the
basic concept, and if we make all the horrible corner cases undefined
we'll still be ok if the future standard does something different.

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.


r~