From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Nov 4 23:08:13 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 B377C35828E; Mon, 4 Nov 2013 23:08:13 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from out.ipsmtp3nec.opaltelecom.net (out.ipsmtp3nec.opaltelecom.net [62.24.202.75]) by www.open-std.org (Postfix) with ESMTP id 44FE6356C22 for ; Mon, 4 Nov 2013 23:07:57 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFAaeFJcFbch/2dsb2JhbAANTIx3s1uCf4FCgxoBAQRTJRELIRYPCQMCAQIBRRMIArMVihmJFI4PgVCELgOQLoEwgk2DX5UvgXE X-IPAS-Result: ApMBAFAaeFJcFbch/2dsb2JhbAANTIx3s1uCf4FCgxoBAQRTJRELIRYPCQMCAQIBRRMIArMVihmJFI4PgVCELgOQLoEwgk2DX5UvgXE X-IronPort-AV: E=Sophos;i="4.93,635,1378854000"; d="txt'?scan'208";a="65725159" Received: from host-92-21-183-33.as13285.net (HELO [192.168.1.18]) ([92.21.183.33]) by out.ipsmtp3nec.opaltelecom.net with ESMTP; 04 Nov 2013 22:07:37 +0000 Message-ID: <52781AA8.4010407@stfc.ac.uk> Date: Mon, 04 Nov 2013 22:07:36 +0000 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 MIME-Version: 1.0 To: sc22wg5@open-std.org Subject: Re: Result of the interpretations ballot 7 References: <4AA982B1265F43408480F737BE12F4D35F87F814@ORSMSX103.amr.corp.intel.com> In-Reply-To: <4AA982B1265F43408480F737BE12F4D35F87F814@ORSMSX103.amr.corp.intel.com> Content-Type: multipart/mixed; boundary="------------050803080404070100000404" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------050803080404070100000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the result of interpretations ballot 7. There were no requests for changes to the draft I sent out last week and the decisions of /INTERP are now included. Now for Corrigendum 3! Best wishes, John. --------------050803080404070100000404 Content-Type: text/plain; charset=windows-1252; name="N1994.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1994.txt" ISO/IEC JTC1/SC22/WG5 N1994 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 C Y Y Y Y Y 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: Pass subject to the change proposed by David Muxworthy. Reasons: The objection raised by Nick Maclaren was considered and rejected in previous rounds of voting. .................................................................... 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: Pass Reasons: In email discussion, Nick Maclaren has not produced a counter-example to Malcolm Cohen's quote of the C standard which specifies that arrays are passed as pointers, i.e. by reference. His suggested alternative answer is not acceptable because it uses circular reasoning. .................................................................... F08/0098 Muxworthy comment: Should new constraint C852a have a reference to R864? Decision of /INTERP: Pass Reasons: BNF rule numbers in constraints are not references. The constraint is correctly worded as is. .................................................................... --------------050803080404070100000404--