From J.Reid@letterbox.rl.ac.uk Mon Oct 10 18:31:31 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA02032 (5.65c8/IDA-1.4.4j for ); Mon, 10 Oct 1994 18:31:31 +0100 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Mon, 10 Oct 94 18:31:18 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Mon, 10 Oct 1994 18:28:23 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA07615; Mon, 10 Oct 94 18:31:01 BST Date: Mon, 10 Oct 94 18:31:01 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9410101731.AA07615@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Re: Enable comments by WG5 member X-Charset: ASCII X-Char-Esc: 29 In working further on the enable proposal, I found that one of my responses was wrong: > > > > > [Footnote: On return to the caller, the condition will be signaling. > > If the invocation is within an enable block that has a handler for the > > condition, there will be a transfer to the handler (or a return or > > stop), but not > > >COMMENT: Delete '(or a return or a stop)'. If the invocation is within an enable > > >COMMENT: block that has a handler for the condition there WILL be a transfer > > >COMMENT: to the handler. There will never be a return or a stop. > > No, the text is correct. The invocation may be within an enable block > that does not have a handler for the condition. > You were correct, but I have decided on a different fix: [Footnote: On return to the caller, the condition will be signaling. If the invocation is within an enable block in which the condition is handled, there will be a transfer to the handler (or a return or stop), but not necessarily until the execution of the block is complete. If the invocation is not within an enable block in which the condition is handled, there may be a return (or stop) at once, or the processor may continue executing.] Best wishes, John.