This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __attribute__((cleanup(function)) versus try/finally
- From: Richard Henderson <rth at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 6 May 2003 17:11:31 -0700
- Subject: Re: __attribute__((cleanup(function)) versus try/finally
- References: <Pine.BSF.4.55.0305061457450.57349@acrux.dbai.tuwien.ac.at> <1052245742.2583.315.camel@doubledemon.codesourcery.com>
On Tue, May 06, 2003 at 11:29:01AM -0700, Mark Mitchell wrote:
> I think RTH accepts the attribute solution as well. He would prefer
> try/finally, as I would prefer no extension, but I think we are both
> willing to accept the attribute.
To some extent I kind-of like the attribute solution on its own.
It provides much more structured access to cleanups than the
arbitrary block of code that __finally allows.
I'm not sure I want to explain to users that jumping out of the
__finally block (via goto/break/return) will lead to undefined
results. It's less difficult to explain that using longjmp out
of a function (under certain conditions) is undefined.
> In fact, that solution delivers maximum performance:
>
> (1) C functions do not need to have handler code inserted.
This is false. Handler code gets inserted with the attribute too.
> (2) You do not have to transfer control from the EH mechanism to the
> stack frame of the caller in order to perform the cleanups.
This is false as well.
Indeed, I'd expect the most common case would be for the cleanup
function to be expanded inline, and reference data cached in
registers in the function.
> The try/finally solution cannot be implemented with this same
> performance; it will, in fact, exact a performance price, in terms of
> both code space and the speed at which cleanups are run, on all
> systems. On systems with setjmp/longjmp exceptions, both costs will be
> very high indeed.
No, the overhead is identical.
r~