(j3.2006) (SC22WG5.4526) WG5 ballot on interpretations

Robert Corbett robert.corbett
Wed Sep 21 05:21:51 EDT 2011

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 
-Y- --- F08/0003   Is a disassociated pointer allowed as an actual DIM
-Y- --- F08/0004   Is TARGET argument of ASSOCIATED a pointer or nonpointer
        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 
-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 
-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


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.


The second proposed edit prohibits the value of a SIZE=
specifier from depending "on any <input-item>."  That
seems to require the value of a SIZE= specifier to be


The last sentence of the proposed interpretation
contradicts the conformance clause of the standard.


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.


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

More information about the J3 mailing list