From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26882 invoked by alias); 8 May 2003 18:40:22 -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 26865 invoked from network); 8 May 2003 18:40:21 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.73.237.138) by sources.redhat.com with SMTP; 8 May 2003 18:40:21 -0000 Received: (qmail 27692 invoked from network); 8 May 2003 18:40:16 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO ?192.168.0.103?) (mitchell@66.60.148.227) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 8 May 2003 18:40:16 -0000 Subject: Re: __attribute__((cleanup(function)) versus try/finally From: Mark Mitchell To: Jason Merrill Cc: Mike Stump , gcc@gcc.gnu.org In-Reply-To: References: Content-Type: text/plain Organization: CodeSourcery, LLC Message-Id: <1052419221.3329.111.camel@minax.codesourcery.com> Mime-Version: 1.0 Date: Thu, 08 May 2003 18:40:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00817.txt.bz2 On Thu, 2003-05-08 at 10:44, Jason Merrill wrote: > On Thu, 8 May 2003 10:44:04 -0700, Mike Stump wrote: > > > On Tuesday, May 6, 2003, at 02:02 PM, Jason Merrill wrote: > >> Hmm, I suppose you can assume that $sp is linear. > > > > One can track discontinuities in an along side data structure at the > > discontinuity creation points, and use that to order the comparisons during > > throw time, should we want to. > > Again, this sort of thing sounds like a cure that's worse than the disease. I think our value-functions are not the same. If we were designing a new language, I'd certainly agree with you that exceptions are a good feature. When discussing C on a workstation-class machine, I'd be more likely to agree with you, even though I think adding exceptions to C is antithetical of that language's key design goals. When discussing C for embedded systems, though, I just can't see it. I fully concede that my scheme is less beautiful -- unless you see beauty in the number of bytes saved. I think what really happened here was that the pthreads designers wanted to add pthread_atexit -- and then got carried away. (In fact, so far as I can tell, a careful reading of http://www.unix.org/single_unix_specification/ would suggest that: pthread_cleanup_push (f, a); goto l; pthread_cleanup_pop (1); l: is well-defined, and does not result in the cleanup being executed. Presumably, this should be undefined behavior, as it does not work at all with the sample implementation in the specification. The question of whether pthread_cleanup_push should create a new scope is also important, at least in C99 and C++: is int i; pthread_cleanup_push (f, a); int i; valid, or not, or is this unspecified?) Also, doesn't the execute argument to pthread_cleanup_pop mean that try/finally isn't the right construct? I would think that the EH version of: pthread_cleanup_push (f, a); g (); pthread_cleanup_pop (x); would be: try { g(); } catch (...) { f(a); throw; } if (x) f(a); -- Mark Mitchell CodeSourcery, LLC