From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Sep 21 11:31:12 2011 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 B71433568E1; Wed, 21 Sep 2011 11:31:12 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by www.open-std.org (Postfix) with ESMTP id E75333567FE for ; Wed, 21 Sep 2011 11:31:10 +0200 (CEST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8L9V6ki006148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Sep 2011 09:31:08 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8L9PqwI012163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Sep 2011 09:25:52 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8L9PlU5017925 for ; Wed, 21 Sep 2011 04:25:47 -0500 Received: from [10.132.140.77] (/10.132.140.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Sep 2011 02:25:47 -0700 Message-ID: <4E79ACAF.9020306@oracle.com> Date: Wed, 21 Sep 2011 02:21:51 -0700 From: Robert Corbett Reply-To: robert.corbett@oracle.com Organization: Oracle America User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.4516) WG5 ballot on interpretations References: <20110823120807.C81523568C1@www.open-std.org> In-Reply-To: <20110823120807.C81523568C1@www.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4E79AEDC.017E:SCFMA922111,ss=1,re=-4.000,fgs=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Yes No Number Title --- -N- F03/0030 IEEE divide by zero -Y- --- F03/0048 Control edit descriptors in UDDTIO -Y- --- F03/0085 Finalizing targets of pointer or allocatable -Y- --- F03/0091 Array components cannot depend on length type parameters --- -N- F03/0096 Can a read statement change the unit value? -Y- --- F03/0105 SIZE= specifier and UDDTIO --- -N- F03/0110 Restoring dropped restriction on ENTRY -C- --- F03/0121 Precise FP semantics of the REAL intrinsic -Y- --- F03/0123 Implicit typing in derived types -Y- --- F03/0124 definition is poorly defined -Y- --- F03/0128 Subobjects in namelist output -Y- --- F08/0001 Generic resolution with pointer dummy arguments -Y- --- F08/0002 Are assumed- or deferred-shape objects allowed in namelist? -Y- --- F08/0003 Is a disassociated pointer allowed as an actual DIM argument? -Y- --- F08/0004 Is TARGET argument of ASSOCIATED a pointer or nonpointer dummy? F08/0005* optional arguments and ASSOCIATED - subsumed by F08/0004 -Y- --- F08/0006 generic resolution with banned argument combinations -Y- --- F08/0007 Can zero have more than one bit sequence representation? --- -N- F08/0008 IEEE exceptions for intrinsic functions -Y- --- F08/0009 Is ABS ever required to be the optional IEC 60559 abs? -Y- --- F08/0010 deallocating objects that are associated with other objects -Y- --- F08/0011 How many times are constructed values finalized? F08/0012* Are constants finalized? - subsumed by F08/0011 -Y- --- F08/0013 How does finalization interact with allocatable assignment? -Y- --- F08/0014 Finalizing assignment to vector-subscripted object -Y- --- F08/0015 IMPLICIT -Y- --- F08/0016 Can a vector-subscripted argument become undefined? -Y- --- F08/0017 Elemental subroutine restrictions -Y- --- F08/0018 Impure elemental restrictions -Y- --- F08/0019 Transformational Bessel functions -Y- --- F08/0020 FINDLOC and logical arguments ----------------------------------------------- F03/0030 The proposed interpretation and edits make no sense unless one assumes that the intent is to redefine and repurpose the function IEEE_SUPPORT_DATATYPE. If that is the intent, the interpretation and edits should address the issue directly instead of modifying seemingly unrelated text. ------------------------------------------------- F03/0096 The second proposed edit prohibits the value of a SIZE= specifier from depending "on any ." That seems to require the value of a SIZE= specifier to be constant. -------------------------------------------------- F03/0110 The last sentence of the proposed interpretation contradicts the conformance clause of the standard. -------------------------------------------------- F03/0121 Fortran programmers need the functionality proposed in the request for interpretation. The mechanism proposed corresponds to what many Fortran programmers already assume to be the case. The committee should either adopt the proposed mechanism or provide an alternative mechanism. -------------------------------------------------- F08/0008 If the statement in the standard that "the flag IEEE_INVALID shall signal" is, as is stated in the interpretation, is incorrect, the text of the standard should be altered to reflect that. -------------------------------------------------- Robert Corbett representing Oracle America