This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [basic-improvements] try/finally support for c/c++


On 06-Nov-2002, Richard Henderson <rth@redhat.com> 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 <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]