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 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


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