From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Oct 21 04:31:42 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 29B1835811C; Mon, 21 Oct 2013 04:31:42 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 708 seconds by postgrey-1.34 at www5.open-std.org; Mon, 21 Oct 2013 04:31:40 CEST Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id ACFB2356A2A for ; Mon, 21 Oct 2013 04:31:26 +0200 (CEST) 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 r9L2JSeh073914 for ; Mon, 21 Oct 2013 02:19:35 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: From: "Malcolm Cohen" To: "WG5" References: <20130924185358.0C92C357284@www.open-std.org> <20131020154033.B1D2E35722C@www.open-std.org> In-Reply-To: <20131020154033.B1D2E35722C@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.5098) WG5 letter ballot 7 on Fortran 2008 interpretations Date: Mon, 21 Oct 2013 11:19:29 +0900 Organization: =?utf-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit 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 Nick Maclaren writes: >F08/0093 > >My vote is "no" solely because this seems to assume 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. 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. This is already assumed by the current text specifying a zero return value for plain STOP, i.e. although in principle I agree that the status return values could be better-specified, this interp is really only about the inconsistent way we went about it. >F08/0096 > >My vote is "no" solely because this makes a statement about C that >cannot be unambiguously deduced from normative text in the C standard, Presumably "C does not have arrays that are passed by value". Since the normative text in the C standard turns array dummies into pointers (and I don't care which translation phase or whatever it happens in), I see nothing controversial about this very straightforward response. The C standard actually says: "A parameter declared to have array or function type is adjusted to have a pointer type as described in 6.9.1.", which further redirects to 6.7.5.3, which says "A declaration of a parameter as ‘‘array of type’’ shall be adjusted to ‘‘qualified pointer to type’’, where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation.". I don't see any deduction needed to understand that array arguments are pointers! On the face of it, "C does not have arrays that are passed by value" is falsifiable via counter-example, so if Nick disputes that then let's see a counter-example. With no counter-example, an argument that the words don't mean that arrays are passed as a pointer to the first element (as described) is unconvincing. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.