From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22092 invoked by alias); 7 Nov 2002 01:45:26 -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 22081 invoked from network); 7 Nov 2002 01:45:24 -0000 Received: from unknown (HELO mulga.cs.mu.OZ.AU) (128.250.1.22) by sources.redhat.com with SMTP; 7 Nov 2002 01:45:24 -0000 Received: from ceres.cs.mu.oz.au (mail@ceres.cs.mu.OZ.AU [128.250.25.4]) by mulga.cs.mu.OZ.AU with ESMTP id MAA23798; Thu, 7 Nov 2002 12:45:08 +1100 (EST) Received: from fjh by ceres.cs.mu.oz.au with local (Exim 3.35 #1 (Debian)) id 189bjI-0001D4-00; Thu, 07 Nov 2002 12:45:08 +1100 Date: Wed, 06 Nov 2002 17:45:00 -0000 From: Fergus Henderson To: Richard Henderson , Aldy Hernandez , "Joseph S. Myers" , gcc-patches@gcc.gnu.org, jakub@redhat.com, jason@redhat.com Subject: Re: [basic-improvements] try/finally support for c/c++ Message-ID: <20021107014507.GB4193@ceres.cs.mu.oz.au> References: <20021106070622.GA31658@redhat.com> <20021106183215.GE7736@redhat.com> <20021106185333.GF22066@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021106185333.GF22066@redhat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-11/txt/msg00394.txt.bz2 On 06-Nov-2002, Richard Henderson wrote: > On Wed, Nov 06, 2002 at 10:32:15AM -0800, Aldy Hernandez wrote: > > > > Richard could you elaborate here? It was my understanding that > > longjmp may not be used to jump into a try/finally block or out of > > one? What are the actual restrictions? > > Well, longjmp pretty much bypasses all the logic one would care to > ask about. I would say that such would have to be undefined. If longjumping out of a try/finally block results in undefined behaviour, then either (1) programmers should avoid using longjmp() (2) programmers should avoid using try/finally (3) programmers must take great care when using longjmp() or try/finally to ensure that the two are not used together in a way that will result in undefined behaviour. This requires global (or at least non-local) analysis of the program. The analysis must be redone whenever any code is added which uses try/finally or longjmp, or even just when code which might use those constructs is rearranged. Furthermore, there are no tools which will help in this analysis, no support for run-time checking of this property, and bugs caused in this way may only show up on some platforms, so on some platforms testing will never detect the bug. OUCH! Which is it? In C++ the answer is (1). This makes sense, because C++ has exceptions, which provide a replacement for longjmp(). But it doesn't work for GNU C with try/finally. (3) is bad since it makes programs using either longjmp() or try/finally much harder to write and maintain. (2) works, but there's no point adding try/finally and then immediately deprecating it ;-) longjmp() is a very useful feature. If you're not going to provide a replacement, then please don't make longjmp() harder to use! > Something I just thought of here is GCC's computed goto extension. Another issue is using goto to jump out of nested functions. This has similar properties to longjmp or throwing exceptions, i.e. it unwinds the stack. The relationship between that and __try/__finally needs to be documented. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp.