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: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Aldy Hernandez <aldyh at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, <jakub at redhat dot com>, <jason at redhat dot com>
- Date: Wed, 6 Nov 2002 08:44:01 +0000 (GMT)
- Subject: Re: [basic-improvements] try/finally support for c/c++
On Tue, 5 Nov 2002, Aldy Hernandez wrote:
> + The @code{__try/__finally} statement consists of a @code{__try} block
"/" should not be in @code here and below.
> + containing one or statements, and a @code{__finally} block contatining
> + one or more statements. The @code{__finally} block will execute after
> + the @code{__try} block but before the code following the
> + @code{__try/__finally} construct, even if the @code{__try} block exits
> + the current function.
There should be a corresponding mention of longjmp to that in the formal
edits.
> + Exiting out of a finally block through a @code{return} or @code{goto}
> + has undefined behaviour.
^^^^ ior
> + 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 (with the exception of program termination or
> + longjump exits out of the try block).
That's @code{longjmp}. Also use consistent terminology; you're using
"@code{__try} block", "__try block" and "try block".
> + 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?
> + A @code{goto}, @code{break}, @code{return}, or @code{continue}
> + statement can be used to transfer control out of a try block but not
> + into one. Also, a longjump may not be used to transfer control into a
> + try or finally block. If done, the behavior is undefined.
@code{longjmp}. May it be used to jump out of such a block? All the
rules that jumps into try blocks are not permitted (and you'll need to add
switch to the statements that might jump into a block) should be listed as
constraints (with corresponding testcases for the errors from the
constraint violations); although violating them at runtime with GNU C
computed gotos would be undefined. May a finally block be jumped into
(and if so, where does execution pass after the finally block is
finished)? May a finally block be jumped out of?
> +
> + statement can be used to transfer control out of a try block but not
> + into one. If such a statement is used to transfer control into
> +
Stray partial paragraph.
--
Joseph S. Myers
jsm28@cam.ac.uk