From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31105 invoked by alias); 5 Nov 2002 23:57:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31098 invoked from network); 5 Nov 2002 23:57:21 -0000 Received: from unknown (HELO mx2.redhat.com) (12.150.115.133) by sources.redhat.com with SMTP; 5 Nov 2002 23:57:21 -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 gA5NtoP18569 for ; Tue, 5 Nov 2002 18:55:50 -0500 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 gA5NvJl25867; Tue, 5 Nov 2002 18:57:19 -0500 Received: from localhost.localdomain (frothingslosh.sfbay.redhat.com [172.16.24.27]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gA5NvID21000; Tue, 5 Nov 2002 15:57:18 -0800 Received: (from rth@localhost) by localhost.localdomain (8.11.6/8.11.6) id gA5NvIe21000; Tue, 5 Nov 2002 15:57:18 -0800 X-Authentication-Warning: localhost.localdomain: rth set sender to rth@redhat.com using -f Date: Tue, 05 Nov 2002 15:57:00 -0000 From: Richard Henderson To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com, jason@redhat.com Subject: Re: [basic-improvements] try/finally support for c/c++ Message-ID: <20021105235718.GC20967@redhat.com> Mail-Followup-To: Richard Henderson , Aldy Hernandez , gcc-patches@gcc.gnu.org, jakub@redhat.com, jason@redhat.com References: <20021105231902.GA13127@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021105231902.GA13127@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00245.txt.bz2 On Tue, Nov 05, 2002 at 03:19:02PM -0800, Aldy Hernandez wrote: > + /* Currently we only support cleanups for C. */ > + if (actions != _UA_CLEANUP_PHASE) > + return _URC_CONTINUE_UNWIND; IIRC, Jakub already pointed out that actions is a bit mask. Should be if (!(actions & _UA_CLEANUP_PHASE)) > + try-finally-statement: > + @b{__try} > + @b{@{} block-item-list @b{@}} > + @b{__finally} > + @b{@{} block-item-list @b{@}} The braces should not be required. This should be @b{__try} @i{statement} @b{__finally} @i{statement} and, indeed, we should have a test for __try q = 1; __finally x = 2; or something. Hmm. I see that C++ *does* require the braces. In which case you should use compound-statment instead of calling block-item-list directly. > + The @code{__try} block is executed. After the __try block exits, > + control is transferred to the @code{__finally} block regardless of how > + the __try block exits. This implies that longjmp is try/finally aware, which is false. Probably should have text similar to C++ 15/2, such that you can't goto into a try handler. (I think that breaks with sjlj exceptions.) > + @node C++98 Try-Finally Edits > + @subsection ISO/IEC 14882:1998 Edits for Try-Finally > + > + @itemize @bullet > + @item > + @cite{2.11 Keywords: Table 3} > + > + Add @code{__finally}. > + Add @code{finally}. "finally" is not a keyword. > + @cite{15 Exception handling} > + > + Rename the @code{handler-seq} production by the following: > + > + @example > + handler-seq: > + handler-seq-catch finally-block > + > + handler-seq-catch: > + handler handler-seq-catch > + > + finally-block: > + @b{__finally} compound-statement > + @end example This says __finally is required. Which is false. Also doesn't indicate that __finally can be used without catch. Should probabably mention that try { A; } catch (...) { B; } __finally { C; } is equivalent to try { try { A; } catch (...) { B; } } __finally { C; } > + Add new text at the end of section 2. > + > + @quotation > + Before control is transferred to the desired destination, the > + __finally block is executed. After such block is executed, control is > + transferred to the desired destination. > + @end quotation There's got to be a better way to say this... Dunno what though. > + @cite{15.1 Throwing an exception} > + > + Add new section before section 2 and 3. > + > + @quotation > + After an exception is caught by an applicable handler (if present), > + but before control is transferred elsewhere (provided the program does > + not exit), the code in the __finally block is executed. > + @end quotation This isn't needed if you define try/finally correctly elsewhere. > + @cite{15.2 Constructors and destructors} > + > + Add new text to section 3. > + > + @quotation > + If code within a @i{try} block (or within code called from a try > + block) causes an exception that is not caught by the subsequent > + @i{catch} blocks, the code in @i{__finally} executes as the stack > + unwinds upwards. > + @end quotation "Upwards" is bad language. See the existing language that uses "path". You probably need to define __finally in terms of destructors in order for this to work out properly. E.g. a finally block is the destructor for an anonymous object of an anonymous type. Or something. Perhaps Jason or Mark could help here? r~