From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Oct 28 23:27:49 2013 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 1EB503581F6; Mon, 28 Oct 2013 23:27:49 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 903 seconds by postgrey-1.34 at www5.open-std.org; Mon, 28 Oct 2013 23:27:48 CET Received: from out.ipsmtp4nec.opaltelecom.net (out.ipsmtp4nec.opaltelecom.net [62.24.202.76]) by www.open-std.org (Postfix) with ESMTP id 9917B356666 for ; Mon, 28 Oct 2013 23:27:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPzgblJcFbch/2dsb2JhbAANTI0DsnuEP4NzJT0WGAMCAQIBSw0IAq0LijaJFJQIA5Atg32DYJUt X-IPAS-Result: ApMBAPzgblJcFbch/2dsb2JhbAANTI0DsnuEP4NzJT0WGAMCAQIBSw0IAq0LijaJFJQIA5Atg32DYJUt X-IronPort-AV: E=Sophos;i="4.93,588,1378854000"; d="txt'?scan'208";a="65441671" Received: from host-92-21-183-33.as13285.net (HELO [127.0.0.1]) ([92.21.183.33]) by out.ipsmtp4nec.opaltelecom.net with ESMTP; 28 Oct 2013 22:12:30 +0000 Message-ID: <526EE1A4.3060600@stfc.ac.uk> Date: Mon, 28 Oct 2013 22:13:56 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: WG5 Subject: Result of the interpretations ballot 7 Content-Type: multipart/mixed; boundary="------------020502090206010801020604" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------020502090206010801020604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is my first draft of the result of interpretations ballot 7. Please let me know by the end of this week if I have made any errors in recording your vote. Cheers, John. --------------020502090206010801020604 Content-Type: text/plain; charset=windows-1252; name="N1994-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1994-1.txt" ISO/IEC JTC1/SC22/WG5 N1994-1 Result of the interpretations ballot 7, N1992 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes noted below. N vote fails. Returned to J3 for further work. F08/ F08/ F08/ F03/ F08/ F08/ F08/ F08/ 0091 0092 0093 0094 0095 0096 0097 0098 Bader Y Y Y Y Y Y Y Y Chen Y Y Y Y Y Y Y Y Cohen Y Y Y Y Y Y Y Y Corbett Y Y N Y Y Y Y Y Long Y Y Y Y Y Y Y Y Maclaren Y Y N Y Y C Y Y Moene Y Y Y Y Y Y Y Y Muxworthy Y Y C Y Y Y Y C Nagle Y Y Y Y Y Y Y Y Reid Y Y Y Y Y Y Y Y Snyder Y Y Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Result Y Y ? Y Y C Y C Comments, reasons for NO votes, and decisions of \INTERP. F08/0093 Corbett No vote: I agree with the objections raised by Nick Maclaren. Maclaren No vote: My vote is "no" solely because this assumes the POSIX view of error status without specifying it. For example, VMS (which is still twitching) uses a different conventions, and zOS is also slightly different. In Fortran 2008 (2.3.5p4, Note 8.30 and 13.7.57p3), there is no implied linkage between the numeric value of the exit status and success or failure. This interpretation introduces such a link. Prepending some description like this to NOTE 2.6a would change my vote: In the recommendations for a program exit status, it is assumed that it is an integer with zero indicating success; processors that use other conventions should interpret the recommendations accordingly. Muxworthy comment: The new line inserted at 460:24+ would be more appropriately placed at 459:17+ since the subclause references in A.2 are otherwise in numerical order. Decision of /INTERP: Reasons: .................................................................... F08/0096 Maclaren comment: This wording makes an assertion about C which cannot be unambiguously deduced from normative text in the C standard, was the topic of extended but inconclusive debates in WG14, and has been and is interpreted in a variety of ways by several derived languages. I would prefer wording that does not make such assertions about C, such as: A1. C does not have any argument passing mechanism for arrays that corresponds to Fortran passing arrays by value, so this was not intended to conform to the Fortran standard. An edit is provided to clarify this. Decision of /INTERP: .................................................................... F08/0098 Muxworthy comment: Should new constraint C852a have a reference to R864? Decision of /INTERP: .................................................................... --------------020502090206010801020604--