This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Aldy Hernandez <aldyh at redhat dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org, jason at redhat dot com
- Date: Wed, 6 Nov 2002 03:51:59 -0500
- Subject: Re: [basic-improvements] try/finally support for c/c++
- References: <20021106070622.GA31658@redhat.com> <Pine.LNX.4.33.0211060830080.11902-100000@kern.srcf.societies.cam.ac.uk>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Nov 06, 2002 at 08:44:01AM +0000, Joseph S. Myers wrote:
> > + The __finally block is guaranteed to execute after the __try block,
> > + provided the program does not terminate while inside such block.
> > + After the __finally block executes, the flow of the program will
> > + continue where the __try block was meant to transfer control to, had
> > + there been no __finally block.
>
> I believe the intention is that variables defined outside the try block
> are live, but variables definied within it are not, while the finally
> block is executing, regardless of how entered? Also, if the try block
> terminates by falling off the end, the intended point of transfer of
> control is after the end of the finally block?
If __try block was exited by return, then the function returns after
finishing the __finally block (unless inside other __try block), if
__try is exited normally, then execution continues after the end
of the finally block, if __try block is exited through exception being
thrown (or forced unwinding), then after __finally block exits the
exception is resumed or forced unwinding continues.
Jakub