This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __attribute__((cleanup(function)) versus try/finally
On May 8, 2003, Mark Mitchell <mark@codesourcery.com> wrote:
> Also, doesn't the execute argument to pthread_cleanup_pop mean that
> try/finally isn't the right construct?
> pthread_cleanup_push (f, a);
> g ();
> pthread_cleanup_pop (x);
> would be:
> try {
> g();
> } catch (...) {
> f(a);
> throw;
> }
> if (x) f(a);
Err... You're not using try/finally above, and you're not necessarily
using the values of f and a that were passed to pthread_cleanup_push.
// expanded from pthread_cleanup_push
if (1) {
void (*__pthr_saved_f)(void *) = (f);
void *__pthr_saved_a = (a);
bool __pthr_execute = true;
try { ;
// end of pthread_cleanup_push
g ();
// expanded from pthread_cleanup_pop
__pthr_execute = x;
} finally {
if (x)
__pthr_saved_f(__pthr_saved_a);
}
} else ;
// end of pthread_cleanup_pop
it's too bad we can't use the cleaner do/while(0) approach for this,
because otherwise we'd change the meaning of break :-(
Fortunately a dangling else does almost as well to eat the `;' after
pthread_cleanup_pop. This still leaves us with an empty statement
after try, but that's not much of a problem.
It's not like this is so important, either... Since
pthread_cleanup_push and pop are even documented to introduce nesting
levels and all, nobody should expect them to expand to a single
statement anyway. But still, we need a scope for the temporaries, so
we might as well go ahead and make them have block begin/end
properties.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer