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

[Zack Weinberg <zack at codesourcery dot com>]

On Thu, Nov 07, 2002 at 02:34:38PM +0100, Michael Matz wrote:
> Hi,
> 
> On Wed, 6 Nov 2002, Mark Mitchell wrote:
> 
> > > #define pthread_cleanup_push(routine_, arg_) \
> > >   __builtin_cleanup_block(routine_, arg_) {
> > >
> > > #define pthread_cleanup_pop(doit_) \
> > >   __builtin_toggle_do_cleanup(doit_); }
> >
> > Something like this is a much, much closer to what I think we should
> > do.
> >
> > Thanks for working this through.
> 
> Uhh, that's exceedingly ugly.  Try to think of the proposed semantic and
> then try to come up with syntax implementing that semantic.  The special
> property of this extension is, that it changes control flow in a very
> non-trivial (but well defined) way.  Every control flow related construct
> in C (except calls) are done by "top-level" keywords and syntactic
> structure (if, while, for, goto ...).  Therefore I'm totally and strictly
> against implementing cleanups with the help of builtins, which have
> function-call like syntax.

I have to say here that I actually _like_ the idea of adding a
try/finally construct to C.  It has a lot of interesting uses
independent of the pthreads cancellation problem.  Java and Python
have it already, so there's plenty of experience with the idiom.
Jakub posted some examples of how it makes code more readable and less
error prone.  It's explicit, which fits C better than destructors.
Using it directly leads to a more natural coding style than
pthread_cleanup_* do, since the cleanup doesn't have to be broken out
to a callback function.

I made up __builtin_cleanup_block and __builtin_toggle_do_cleanup to
address a specific difficulty with implementing pthread_cleanup_push/pop 
in terms of try/finally, which is: when you write out the macros as
they would need to appear, you discover that they're asking to be
broken by user code playing around with the preprocessor.  Also it is
impossible to write them in a way that won't produce unavoidable
-Wshadow warnings if you have nested pthread_cleanup_push/pop blocks.

Please note that __builtin_cleanup_block is _not_ a builtin function,
despite the name; it's a control flow keyword with the rough semantic
of 'establish a cleanup for the block immediately following, which
calls ROUTINE with sole argument ARG if (the cleanup was reached
because an exception was thrown || the DOIT flag is true).
__builtin_toggle_do_cleanup is a builtin function, but it doesn't
affect control flow; it just writes the value of its sole argument
into the DOIT flag, which is an invisible variable.

zw