From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5843 invoked by alias); 7 May 2003 00:14:01 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5820 invoked from network); 7 May 2003 00:14:00 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 7 May 2003 00:14:00 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id h4703TZ00308; Tue, 6 May 2003 20:03:29 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h470DxT18669; Tue, 6 May 2003 20:13:59 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h470DxM04794; Tue, 6 May 2003 17:13:59 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id h470BVU07645; Tue, 6 May 2003 17:11:31 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Wed, 07 May 2003 00:14:00 -0000 From: Richard Henderson To: Mark Mitchell Cc: gcc@gcc.gnu.org Subject: Re: __attribute__((cleanup(function)) versus try/finally Message-ID: <20030507001131.GI7564@redhat.com> Mail-Followup-To: Richard Henderson , Mark Mitchell , gcc@gcc.gnu.org References: <1052245742.2583.315.camel@doubledemon.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1052245742.2583.315.camel@doubledemon.codesourcery.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-05/txt/msg00562.txt.bz2 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~