(j3.2006) J3/09-292 - J3 Fortran interp letter ballot #19 - due19-Oct-2009
Robert Corbett
Robert.Corbett
Mon Oct 19 05:05:20 EDT 2009
Yes No Number Title
--- -N- F95/0098 Are dummy functions returning assumed-length
character legal?
--- -N- F03/0022 Coexistence of IEEE and non-IEEE kinds
--- -N- F03/0024 DEALLOCATE and array pointers
-C- --- F03/0034 IEEE_LOGB()
--- -N- F03/0039 HYPOT()
-Y- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence
-C- --- F03/0090 Polymorphic array constructors
-Y- --- F03/0130 Elemental specific intrinsic procedure
characteristics
--- -N- F03/0131 SAVE attribute and EQUIVALENCE
-Y- --- F03/0132 Unformatted i/o and private components
-C- --- 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
--- -N- F03/0136 Are subroutines distinguishable from arrays?
--- -N- F03/0137 Dummy procedure type compatibility
--- -N- F03/0138 External <procedure-name> as <proc-target>
-----------------------------------------------------------------
Comments on F95/0098
This interpretation stands the original design of assumed-length
CHARACTER dummy functions on its head. This interpretation
specifies that the length used for an invocation of an
assumed-length dummy function is the length specified for the
external function passed to the first dummy procedure in the
chain leading to the dummy function used in the invocation. That
leads to examples that contradict basic principles that underlie
the design of FORTRAN 77, the standard in which assumed-length
CHARACTER dummy functions were introduced, being considered
standard-conforming.
Under the interpretation given, the following program is a
standard-conforming program:
CHARACTER*(*) FUNCTION F(C)
CHARACTER C
F = C
END
SUBROUTINE SUBR1(S1, S2, S3)
CHARACTER*(*) S1, S2, S3
PRINT '(A)', S1
PRINT '(A)', S2
PRINT '(A)', S3
END
SUBROUTINE SUBR2(F)
CHARACTER*(*) F
EXTERNAL F
CALL SUBR1(F('A'), F('B'), F('C'))
END
PROGRAM MAIN
CHARACTER*20 F
EXTERNAL F
CALL SUBR2(F)
END
FORTRAN 77 was designed to allow separate compilation and to allow
implementations that allocate all storage statically. Subroutine
SUBR2 cannot be implemented under those constraints. Space for the
three actual arguments passed to SUBR1 in the CALL statement cannot
be allocated statically because the size of the space needed is not
known when SUBR2 is compiled. The FORTRAN 77 standard avoids this
problem by requiring the length of the function result to be
specified as an integer constant expression. Section 8.4.2 of the
FORTRAN 77 standard [page 8-7, lines 5 - 9] states
The length specified for a character function in the
program unit that references the function must be an
integer constant expression and must agree with the
length specified in the subprogram that specifies the
function. Note that there always is agreement of
length if a _len_ of (*) is specified in the
subprogram that specifies the function.
That restriction, which is essential to avoid the need for dynamic
storage allocation contradicts the statement that the length of
the dummy function is assumed from the associated actual parameter.
That is why I believe that statement applies only to assumed-length
CHARACTER dummy variables and not to assumed-length CHARACTER dummy
functions.
Although many FORTRAN 77 compilers accepted subprograms such as
SUBR2, they were not required to do so. Many FORTRAN 77 compilers,
including AT&T's UNIX f77 compiler, did reject such subprograms.
I believe that the answers to the questions raised in F95/0098
should be
(1) yes,
(2) no,
(3) not directly applicable, because the question is
conditioned on the answer to (2) being "yes";
however, the answer to the question whether an
external function may have an assumed-length
CHARACTER result variable should be yes,
(4) yes,
(5) an edit is needed.
I believe that the edits proposed by John Reid in meeting paper
J3/09-261 properly resolve these issues.
-----------------------------------------------------------------
Comments on F03/0022
Note 14.2 in Section 14 of the Fortran 2003 standard states
IEEE_INVALID is not required to be supported whenever
IEEE_EXCEPTIONS is accessed. This is to allow a
non-IEEE processor to provide support for overflow
and divide-by-zero.
This note makes it clear that the requirement in the normative
text [page 363, lines 8 - 9] is intended to apply to non-IEEE
kinds as well as IEEE kinds of real and complex data. I assume
that the rationale for this requirement is that support for
overflow and divide-by-zero exceptions is so nearly universal
that nothing is lost by including the requirement. The same is
not true for invalid and inexact exceptions.
I believe that no edits are required.
-----------------------------------------------------------------
Comments on F03/0024
I am satisfied with most of the response to F03/0024. The only
point that concerns me is the difference between the answers
for questions Q4 and Q5. I think the answers to Q4 and Q5
should either be that both are conforming or that both are not
conforming. Either the rank of the allocated object should be
required equal the rank of the pointer being freed, or an array
of one element should be allowed to be freed through a scalar
pointer. I lean slightly toward requiring the rank and shape of
the pointer to match the rank and shape of the allocated object.
Such a restriction would simplify implementation of finalizers.
-----------------------------------------------------------------
Comment on F03/0034
The following comment is intended as a point of information,
not a criticism of the answer given.
The answer given is correct for IEC 60559, which is the
standard referenced by the Fortran 2003 standard. In
IEEE Std. 754-2008, the definition of logb has changed.
The definition of IEEE_LOGB does not match that new
definition.
-----------------------------------------------------------------
Comment on F03/0039
I do not see the point in adding anything to the example
given in Note 14.17. The first sentence of the answer
given in the ANSWER section of the interpretation is a
sufficient answer to the question. The proposed addition
to the example clutters the code and obscures the point
of the example.
I believe no edits are required.
-----------------------------------------------------------------
Comment on F03/0090
There are typos in the examples given. The names of the
function and the names of the result variables should
match.
While reading the standard to research this interpretation
I found that there is a need for a similar edit regarding
the type of the expression on the right-hand side of an
intrinsic assignment statement. I suspect there are more
cases where the standard says simply "type" when it should
say "declared type."
-----------------------------------------------------------------
Comment on F03/0131
The edits provided with this interpretation are a big change
to fix a small problem. There is a big problem that the
edits also fix, but I think the issues regarding that big
problem should be considered before committing to a
particular fix for it.
The SAVE attribute has two principal effects: variables that
have the SAVE attribute or that are in common blocks that have
the SAVE attribute retain their values across procedure calls,
and variables that have the SAVE attribute are shared by all
instances of a subprogram. The first effect was introduced in
the FORTRAN 77 standard. The second was introduced in the
Fortran 90 standard.
I have seen arguments that the attributes are not transmitted
through equivalence. I have seen that argument made for the
attributes ASYNCHRONOUS, VOLATILE, and SAVE. I accepted those
arguments, and I repeated them. For the attributes
ASYNCHRONOUS and VOLATILE, those arguments are sustainable.
For the attribute SAVE there is a problem. The Fortran 90,
Fortran 95, and Fortran 2003 standard require a processor to
create new instances of local unsaved data objects when a
function or subroutine is invoked. Because variables with the
SAVE attribute are shared by all instances of a subprogram,
that is a problem.
I thought there must be a statement in the standard or among
the interpretations that addresses this problem, but I was
unable to find such a statement. I would not be surprised to
learn that there is such a statement that I overlooked.
The change proposed in this interpretation has a bigger effect
than is necessary to solve both the original problem and the
problem I described. The proposed change prohibits some
optimizations that could be allowed with other fixes for the
problems.
I propose the following alterative edits:
[282:34] Change "local unsaved data objects." to
"local data objects that do not have the SAVE attribute
and that are not in an equivalence set with a data object
that has the SAVE attribute."
[421:33-34] Change
"an unsaved nonpointer nonallocatable local variable" to
"a nonpointer nonallocatable local variable that does not
have the SAVE attribute and that is not in an equivalence
set with a data object that has the SAVE attribute"
These edits allow optimizations that would be prohibited by the
first principal effect of the SAVE attribute.
-----------------------------------------------------------------
Comments on F03/133
I think it would be clearer for most readers to say "a
polymorphic variable" instead of "an unlimited polymorphic
Pointer". I understand that this wording would cause C588
to partially overlap C589. I don't think that is a problem.
-----------------------------------------------------------------
Comments on F03/0136
I do not care for this change. I do not know of a technical
problem with this change, but I see no compelling reason to
make this change. I see no reason to suppose that the
"inconsistency" was inadvertent.
I believe no edits are required.
-----------------------------------------------------------------
Comments on F03/0137
I have come to believe that the reason the Fortran 90 standard
does not include a requirement that the type of the actual
argument passed to a dummy procedure with implicit interface
match the type of the dummy procedure is that the authors of
that standard did not intend to impose such a requirement. I
believe that the Fortran 95 and Fortran 2003 standards do not
include such a requirement because the Fortran 90 standard
does not.
There is no need for the interface of a dummy procedure to match
the characteristics of the associated procedure unless the dummy
procedure is invoked. Section 12.3 [p257:10] states
The interface of a procedure determines the forms of
reference through which it may be invoked.
That statement can be taken as a requirement that the interface
must match when a procedure is invoked, but it says nothing about
the requirements when a procedure is passed as an argument.
Technically, there is no need for the type of an actual argument
to match the type of the corresponding dummy procedure unless the
dummy procedure is invoked. Standard C has rules that are even
more lax. This subject was discussed during development of the
C standard, which overlapped the development of the Fortran 90
standard. At least some of the people involved in the development
of the Fortran 90 standard would have known about issues involved
in the development of standard C.
The change proposed in this interpretation would cause programs
that currently conform to the requirements of the Fortran 2003
standard to become nonconforming. There is no technical need
to add the proposed restriction. Therefore, I oppose to the
proposed change.
I believe there is no need for a change to the normative text
of the standard. I think a note explaining that the absence of
a requirement that the types must match is intentional would be
helpful to readers.
-----------------------------------------------------------------
Comments on F03/0138
I do not see why the second example should not be considered
standard conforming. The identifier "x" in the pointer
assignment in the program example2 is clearly the name of an
external procedure. There is no need for it to be used in a
CALL statement to establish that it is an external procedure.
I believe no edits are required.
More information about the J3
mailing list