From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Jan 19 02:59:35 2015 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 857B635849D; Mon, 19 Jan 2015 02:59:35 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 7C61F356E63 for ; Mon, 19 Jan 2015 02:59:28 +0100 (CET) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id t0J1xNKG076565 for ; Mon, 19 Jan 2015 10:59:25 +0900 (JST) (envelope-from malcolm@nag-j.co.jp) Message-ID: From: "Malcolm Cohen" To: References: <20150117130059.8B96B358262@www.open-std.org> In-Reply-To: <20150117130059.8B96B358262@www.open-std.org> Subject: Re: WG5 straw ballot on N2040 Date: Mon, 19 Jan 2015 10:59:22 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk 3) No, for the following reasons. (a) I agree with Robert Corbett's vote. My recommendation is that the transfer of control to the END TEAM statement should be available only for access to failed image data from within the CHANGE TEAM construct itself. (a2) 5.9 states "Otherwise, the executing image resumes execution at the END TEAM statement of the construct" "the construct" lacks definition. There can be many CHANGE TEAM constructs, and more than one of them can be active. Presumably what is meant is either (i) the innermost such construct or (ii) the innermost such construct whose END TEAM statement has a STAT= specifier. This needs to be explicitly stated. I note that in the case of executing code outside (but called from) a CHANGE TEAM construct, "innermost" has no meaning. (b) The TS has merely scratched the surface of the semantics that are being specified for stalled image handling; much more work needs to be done to clarify what is supposed to happen (e.g. which variables become undefined, etc.). Even for failed images some additional work appears to be needed... (c) I do not agree with the syntax for specifying a team variable in an image-selector, as we use double colons following type-specs and other related attributes, which this is certainly not. A single colon would be acceptable. (d) FAIL IMAGE is insufficiently specified. - The syntax is "FAIL IMAGE ". I see no purpose in using the BNF rule here. - "Execution of a FAIL IMAGE statement causes the executing image to behave as if it has failed." I think that should be "...become a failed image." - " No further statements are executed by that image." I think it would be clearer to state explicitly that image termination is not initiated by this statement, e.g. " Neither normal nor error termination is initiated, but no further statements are executed by that image." - "When an image executes a FAIL IMAGE statement, its stop code, if any, is made available in a processor-dependent manner." This is not only completely useless, but also missing any useful recommendation; e.g. for STOP and ERROR STOP we recommend "formatted output to [ERROR_UNIT]". (e) Clause 1 states "This Technical Specification does not specify formal data consistency or progress models. Some level of asynchronous progress is required to ensure that the examples in clauses 6 and 7 are conforming." - point 1: there are no examples in clause 6; - point 2: I found no useful examples in clause 7, by which I mean any that are bigger than 1 statement and that make any use of data consistency or asynchronous progress; - point 3: were there useful examples the question would not be whether they were conforming, but whether they WORKED on any conforming implementation of the TS. (f) Clause 1 continues "Developing the formal data consistency and progress models is left until the integration of these facilities into ISO/IEC 1539-1." We need to get started on this straightaway, not leave it to the last minute. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.