From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Aug 29 12:56:09 2012 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 165A93568FF; Wed, 29 Aug 2012 12:56:09 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-1-a-1.mail.uk.tiscali.com (mk-filter-1-a-1.mail.tiscali.co.uk [212.74.100.52]) by www.open-std.org (Postfix) with ESMTP id 479453568F1 for ; Wed, 29 Aug 2012 12:56:06 +0200 (CEST) X-Trace: 810538818/mk-filter-1.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/2.97.125.94/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.97.125.94 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAL70PVACYX1e/2dsb2JhbAANOL4XAQEEOBsfBhELIRYPCQMCAQIBRQYNCAKvWYp+iQSRYQOVVoVJjTA X-IronPort-AV: E=Sophos;i="4.80,333,1344207600"; d="scan'208";a="810538818" Received: from host-2-97-125-94.as13285.net (HELO [127.0.0.1]) ([2.97.125.94]) by smtp.tiscali.co.uk with ESMTP; 29 Aug 2012 11:56:04 +0100 Message-ID: <503DF54C.7000601@stfc.ac.uk> Date: Wed, 29 Aug 2012 11:56:12 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 MIME-Version: 1.0 To: sc22wg5 Subject: Re: Ballot 3 on Fortran 2008 interpretations References: <20120804040444.460F63568DA@www.open-std.org> <20120806212738.70CE53568F2@www.open-std.org> <20120807182349.20E743568F8@www.open-std.org> <502F834A.6080405@stfc.ac.uk> In-Reply-To: <502F834A.6080405@stfc.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk WG5, David's comment on F03/0121 led me to look again at this interpretation and decide that I want to change my vote. Here is my complete ballot with this change included. Yes No Number Title -Y- --- F03/0017 Dummy procedure pointers and PRESENT -Y- --- F03/0018 Multiple identical specific procedures in type-bound generic interfaces -Y- --- F03/0019 Multiple identical specific procedures in generic interface blocks -Y- --- F03/0021 What kind of token is a stop code? -Y- --- F03/0046 Unlimited polymorphic pointers in common blocks --- -N- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0065 Relational equivalence --- -N- F03/0084 IEEE_SET_ROUNDING_MODE in a subroutine -Y- --- F03/0096 Can a read statement change the unit value? -Y- --- F03/0103 Restrictions on dummy arguments not present for polymorphic type or parameterized derived type -Y- --- F03/0116 indistinguishable specifics for a generic interface with use association -Y- --- F03/0118 Are lower bounds of assumed-shape arrays assumed? -Y- --- F03/0120 When are parameterized sequence types the same type? --- -N- F03/0121 Precise FP semantics of the REAL intrinsic -Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? -Y- --- F08/0008 IEEE exceptions for intrinsic functions -Y- --- F08/0031 PURE INTENT(OUT) finalization -Y- --- F08/0032 PURE FUNCTION result finalization -Y- --- F08/0038 Are pointless restrictions on DIM arguments intended? -Y- --- F08/0042 SOURCE= questions Reasons for NO votes F03/0053 1. I remain of the opinion that 15.3.3 should state clearly that C_PTR and C_FUNPTR do not have the BIND attribute. It is counter- intuitive that they are interoperable and yet do not have the BIND attribute. They are defined in an intrinsic module so the reader cannot look at the definition. The present text relies on the distinction between "derived type" in 15.3.3 and "Fortran derived type" in 15.3.4. The term "Fortran derived type" is undefined and is not used anywhere else in the standard (as far as I can see). The text of 15.3.3 is similar to 15.2.2 in the Fortran 2003 standard. In N1622, J3 thought it was unclear and proposed editing 15.2.2 to say that these types do have the BIND attribute. I suggest the edit: [431:2] 15.3.3, para 1. At the end of sentence 1 add "and without the BIND attribute". 2. Was it really intended that a user-defined derived type with the BIND attribute be permitted to have private components? It seems to me that this should not be permitted since it destroys the purpose of declaring components to be private. If it was intended, the rationale should be included in the answer - this is, after all, an interpretation. F03/0084: The IEEE rounding mode on entry to the procedure may vary from call to call. The value of Z1 depends on this rounding mode. Therefore, the processor should not always print zero for Z1-Z2. Whether or not Z1 and Z2 have the PARAMETER attribute makes no difference. Yes, the processor is allowed to evaluate an expression in any mathematically equivalent way, but here the mathematics dictates that a particular form of rounding, defined in the IEEE standard, be applied. F03/0121: I think it is unacceptable to recommend the use of the VOLATILE attribute for a variable that is referenced, defi ned, or becomes undefi ned only within the Fortran program. The desired effect may be obtained by assigning the intermediate result to a variable without the VOLATILE attribute because this rules out the exceptions explained in the final sentence of the first paragraph of the answer ("Furthermore, ...").