(j3.2006) (SC22WG5.4188) letter ballot on interps

Robert Corbett Robert.Corbett
Sun Feb 14 05:13:39 EST 2010

Yes  No Number     Title
--- -N- F95/0098 Are dummy functions returning assumed-length character 
--- -N- F03/0022 Coexistence of IEEE and non-IEEE kinds
-Y- --- F03/0024 DEALLOCATE and array pointers
-C- --- F03/0034 IEEE_LOGB()
--- -N- F03/0039 HYPOT()
--- -N- F03/0063 Procedure pointers in BLOCK DATA program units
-Y- --- F03/0071 Subroutine/function ambiguity in generics
-C- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence
-Y- --- F03/0090 Polymorphic array constructors
-Y- --- F03/0112 Attributes allowed for dummy arguments in defined 
-Y- --- F03/0119 Elemental procedures and deferred length character 
-Y- --- F03/0122 When do objects of sequence derived type have the same 
-Y- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS
-Y- --- F03/0126 References to VOLATILE variables in pure procedures
-Y- --- F03/0127 Duration of procedure execution
-Y- --- F03/0129 C_LOC of character substrings
-Y- --- F03/0130 Elemental specific intrinsic procedure characteristics
--- -N- F03/0131 SAVE attribute and EQUIVALENCE
-Y- --- F03/0132 Unformatted i/o and private components
-Y- --- F03/0133 Is unlimited polymorphic allowed in COMMON?
-Y- --- F03/0134 Implicit typing of procedure pointers
-Y- --- F03/0135 Interaction between RESULT, recursion, and host generic
-Y- --- F03/0136 Are subroutines distinguishable from arrays?
--- -N- F03/0137 Dummy procedure type compatibility
--- -N- F03/0138 External <procedure-name> as <proc-target>
-Y- --- F03/0139 Functions returning procedure pointers
-Y- --- F03/0140 Type of nested construct entities
-Y- --- F03/0141 More than one specific interface for a procedure

Assumed-length character dummy functions are an obsolescent feature
included for FORTRAN 77 compatibility.  The answer given here is
incompatible with the specification of assumed-length character
dummy functions in FORTRAN 77.  Section 15.2 of the FORTRAN 77
standard [page 15-2, 5-8] states

      If a character function is referenced in a program unit,
      the function length specified in the program unit must be
      an integer constant expression.

Item (4) in the last paragraph of Section of the Fortran
2003 standard [page 41, 34-37] should be interpreted as specifying
the same requirement.

The proposed interpretation requires variable amounts of space to
be allocated for character returning functions.  The FORTRAN 77
standard was designed to allow implementations that use only static
storage allocation.  Thus, the proposed implementation cannot be
the interpretation intended by the FORTRAN 77 standard.

Note 14.2 strongly suggests that the restriction imposed by the
text in question was intended.  The change in the proposed
interpretation serves no purpose for any architecture of which I
am aware.

The proposed interpretation is compatible with the 1985 edition
of IEEE Std. 754.  The definition of logb changed in the 2008
edition of IEEE Std. 754.  I do not object to using the old
definition of logb (I voted C, not N), but it might be worth
noting the difference.

The proposed change obscures the point that the example given in
Note 14.17 is intended to make.

I agree with the comments of others that the proposed interpretation
makes the IEEE modules less useful.

The proposed interpretation imposes unnecessary limitations on
the optimizations allowed.  Variables should not acquire the
SAVE attribute by contagion.

The proposed interpretation makes codes that once conformed to
the written requirements of the standard nonconformant.
Furthermore, there is no obvious way to mechanically translate
those codes into conforming codes.  The restriction offered in
the proposed interpretation should be rejected.

I agree with Reinhold Bader's observation that the targets of
procedure pointer assignments should be assumed to be procedures.

More information about the J3 mailing list