J3 paper 00-209
To: J3 Members Date: 30-May-2000
From: interp
Subj: Further results of the F95 interp letter ballot #1
Here are the results of J3 letter ballot #1 on Fortran 95
interpretations that closed on 19-May-2000.
This paper includes status of interps 71, 76, 79,80, 83, after further consideration by
interp, changes are bolded.
The summary of results is as follows:
P = passed 66 67 68 69 70 71 72 76 77 79 80 82 83 84
C = passed as amended F F F C F P C C C C C C P P
F = further consideration
The interps marked "F" will be reconsidered at J3 meeting #153 by the
/interp committee who will decide if the status becomes "withdraw for
more work", "passed as amended", or "passed as printed".
**********************************************************************
We added some <>'s, amended the status/history.
NUMBER: 000069
TITLE: What is a numeric character?
KEYWORDS: list-directed input
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
Section 10.8.1 of
the Fortran 95 standard states
If the next effective item is of type default
character and ...
(4) The leading characters are not
numeric followed by an asterisk, ...
The standard does not define what a numeric character is.
QUESTION:
What is a numeric character?
ANSWER:
A numeric character is a .
REFERENCES: ISO/IEC 1539-1:1997(E), Section 10.8.1
EDITS:
In Fortran 95, section 10.8.1, list item (4), [176:17],
replace the text
(4) The leading characters are not numeric followed by an asterisk
with
(4) The leading characters are not s
followed by an asterisk
In 99-007r2, section 10.9.1, list item (4), [244:32],
replace the text
(4) The leading characters are not numeric followed by an asterisk
with
(4) The leading characters are not s
followed by an asterisk
SUBMITTED BY: Robert Corbett
HISTORY: J3/99-191 m150 Submitted by Robert Corbett
J3/99-214 m150 J3 draft response, approved uc
J3/00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We made no changes to 71. We decided not to extend F95.
NUMBER: 000071
TITLE: Character array constructors
KEYWORDS: Character, array constructor, zero-size
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
The f95 standard appears to leave the length of zero-sized character array
constructors undefined. The penultimate paragraph of clause 4.5 says
"The type and parameters of an array constructor are those of the
expressions."
If there are no elements, then the values of the type parameters might not be
defined. The type and kind are always well defined at compile time. However,
the length parameter for zero-sized character array constructors is not
obviously well-defined, even at run-time.
Zero-sized constructors are certainly allowed, as mentioned in the
antipenultimate paragraph of clause 4.5:
"An empty sequence forms a zero-sized rank-one array."
Experimentation with different f90 compilers yields varying results.
QUESTION 1:
Is the following a valid program and, if so, what len value does it print.
program zero
write (*,*) len( (/ ('abc', i = 1 , 0) /) )
end
QUESTION 2:
Is the following a valid program and, if so, what value does it print.
program zero_size
integer :: n = 0
call sub('abcdefghij', n)
contains
subroutine sub(string, n)
character*(*) :: string
integer :: n
integer :: i
write (*,*) len( (/ (string(:i+2), i = 1 , n) /) )
end subroutine
end program zero_size
QUESTION 3:
Is the following a valid program and, if so, what values does it print
for the lengths and for n_calls.
program zero_size
integer :: n = 0
integer :: n_calls = 0
call sub('abcdefghij', n)
write (*,*) 'n_calls = ', n_calls
contains
subroutine sub(string, n)
character*(*) :: string
integer :: n
integer :: i
write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) )
end subroutine sub
integer function f(i)
f = 2*i + 5
n_calls = n_calls + 1
end function f
end program zero_size
ANSWER:
(1) Yes. The length is 3.
Clause 4.5 says that
"The type and type parameters of an array constructor are those of the
expressions."
There is no exclusion for s that contribute no elements to the
value of the array constructor: thus s that are inside zero-trip
implied DO loops still contribute their "type" information.
The example array constructor has an that is the character
literal 'abc'; this clearly has the character length of 3 and therefore
the array constructor has a character length of 3.
The description of how an that is an implied DO is handled
confuses syntax and semantics: an edit is supplied to clarify this.
(2) No. The edits below clarify this situation.
(3) Yes. The length printed is 5, n_calls is still zero.
Clause 4.5 says that
"If the expressions are of type character, each
expression in the shall have the same character
length parameter."
The example array constructor has an that is the character
literal 'abcde'; this clearly has the character length of 5 and therefore
the array constructor has a character length of 5.
No references to the function F are executed because these appear within
a zero-trip implied DO loop.
EDITS:
In clause 4.5, in the paragraph beginning
"If an is a scalar expression"
[46:1] replace:
"an sequence"
with
"a sequence of elements".
In clause 4.5, at the end of the paragraph which begins "If the
expressions are of type character" [45:38+], insert:
"A zero-sized character array constructor shall have at least one
that is an initialization expression, a that does not contain
a , or a containing a in
which all expressions are initialization expressions."
SUBMITTED BY: Richard Maine
HISTORY: 98-101 m144 submitted 20 Nov 1997
99-207 m150 additional input
99-217r3 m150 approved uc
00-209 m153 passed by J3 letter ballot
We fixed the spelling of "nonelemental".
NUMBER: 000072
TITLE: Resolving generic procedure references
KEYWORDS: generic, ELEMENTAL
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider
INTERFACE generic
ELEMENTAL SUBROUTINE sub_e(a)
REAL,INTENT(INOUT) :: a
END
SUBROUTINE sub_3(a)
REAL,INTENT(INOUT) :: a(:,:,:)
END
END INTERFACE
This is legal (it obeys the restrictions in 14.1.2.3).
This allows the ambiguous reference
REAL x(10,20,30)
CALL generic(x)
However, the existing text in 14.1.2.4.1 does not explain which procedure is
called, because the reference is consistent with two procedures. Note 14.6
indicates that the intent is to call the nonelemental procedure in this case.
Is note 14.6 correct as to the intent of the standard?
ANSWER:
Yes, note 14.6 is correct; an edit is supplied to the resolution rules to
implement this.
EDIT:
[278:41] After "with" insert "a non-elemental reference to".
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-218 m150 submitted, approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We accepted Henry's comment.
NUMBER: 000076
TITLE: INTENT(IN) dummy arguments and implied DO loops
KEYWORDS: INTENT(IN), implied DO
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
The Fortran 95 standard [53:13-17] says
"Constraint: A dummy argument with the INTENT(IN) attribute ... shall not
appear as
...
(3) A DO variable or implied-DO variable,
..."
The apparent intent is to prevent any modification of the dummy argument;
however, use in data-implied-do and array-constructor-implied-do would not
modify the dummy argument.
Is the constraint intentionally stronger than necessary?
ANSWER:
The constraint is only intended to apply to implied-DO variables in I/O lists.
The following edit makes this clearer.
EDIT:
[53:17] Change "A DO variable or implied-DO variable"
to "A in a or ".
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-199 m150 submitted
99-199r1 m150 approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We accepted Henry's comment.
NUMBER: 000077
TITLE: INTENT(IN) dummy arguments and NULLIFY
KEYWORDS: INTENT(IN), NULLIFY
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
The Fortran 95 standard [53:13-17] says
"Constraint: A dummy argument with the INTENT(IN) attribute, or a subobject of
such a dummy argument, shall not appear as
...
(2) The of a ,
..."
Consider:
TYPE t
REAL,POINTER :: value
END TYPE
...
SUBROUTINE s(x)
TYPE(t),INTENT(IN) :: x
IF (.FALSE.) x%value => NULL() ! (1)
IF (.FALSE.) NULLIFY(x%value) ! (2)
According to the constraint above, line (1) is illegal.
However, there is no corresponding constraint for the NULLIFY statement,
implying that line (2) is legal.
Should subobjects of INTENT(IN) dummies also be constrained against
appearing as the of a NULLIFY statement?
ANSWER:
Yes, there should be a constraint disallowing INTENT(IN) dummy arguments in
a NULLIFY statement. The edit below corrects this omission.
EDIT:
Replace constraint (2) with "The in a
or ,"
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-200 m150 submitted
99-200r1 m150 approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We changed the keywords and marked the edit to F2000 for future action.
NUMBER: 000079
TITLE: Pointer Assignment and Allocatable Arrays
KEYWORDS: Pointer assignment, allocatable
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
Consider
PROGRAM p
REAL,ALLOCATABLE,TARGET :: x(:)
POINTER p(:)
p => x
ALLOCATE(x(10))
PRINT *,SIZE(p)
END
This appears to be a legal program - there seems to be no prohibition against
pointer assignment to an unallocated allocatable array and allocating the array
does not seem to alter the association status of any pointer associated with an
allocatable array.
Should there be a prohibition against pointer assignment to an unallocated
allocatable array?
ANSWER:
Yes; an edit is supplied to correct this oversight.
EDIT:
In clause 7.5.2, at the end of the paragraph that begins "The shall"
[111:8+], insert:
"If the is an allocatable array, it shall be currently allocated."
Possible EDIT to 99-007r2:
[156:7+] add to end of paragraph:
"If the is allocatable it shall be currently allocated."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-223 m150 submitted, approved 6-4
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We accepted Henry's fix.
NUMBER: 000080
TITLE: Host association and the EXTERNAL attribute
KEYWORDS: Host association, EXTERNAL
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Use of a (non-intrinsic) name as a procedure in a procedure reference
implicitly confers the EXTERNAL attribute on the name. Does this happen
when the name is host-associated?
For example, f90 interp 143 established that
MODULE m1
REAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
was invalid - 11.3.2 now says that a "procedure with implicit interface and
public accessibility shall explicitly be given the EXTERNAL attribute in the
scoping unit of the module".
However, this text says nothing about private entities, so considering:
MODULE m2
REAL,PRIVATE :: x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
This example does not violate 11.3.2 because X is PRIVATE.
Is this example conforming?
Further, considering:
PROGRAM m3
REAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
This example is not of a module and so 11.3.2 does not apply.
Is this example conforming?
Further, considering
PROGRAM m4
EXTERNAL x
CONTAINS
SUBROUTINE s
PRINT *,x(1)
END SUBROUTINE
END
Does the invocation as a function in an internal procedure cause X to be
implicitly typed, or is this not conforming?
ANSWER:
No, use of a host-associated name never confers attributes on the host entity.
Examples M2, M3, and M4 are therefore invalid.
Edits are supplied.
EDIT:
[188:28] Delete "and public accessibility".
[188:31] Delete "with public accessibility".
[283:16+] Add new paragraph after the note
"An external or dummy procedure with an implicit interface that is accessed via host
association
shall explicitly be given the EXTERNAL attribute in the host scoping unit or
be used as a procedure in that scoping unit; if it is invoked as a function
in the inner scoping unit, its type and type parameters shall be explicitly
declared in a type declaration statement in the host scoping unit. An
intrinsic procedure that is accessed via host association shall explicitly be
given the INTRINSIC attribute in the host scoping unit or be used as an
intrinsic procedure in that scoping unit."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-230 m151 submitted
99-230r1 m151 approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We accepted Henry's comment.
NUMBER: 000082
TITLE: Usage of BOZ literal constants
KEYWORDS: BOZ constant
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Consider:
INTEGER X(10)
DATA X(B"001")/42/
END
This is apparently conforming, since the constraint at [32:15] says
"A may appear only in a DATA statement."
But this rules out
X(B"001") = 42
Is this an error?
ANSWER:
Yes, BOZ literal constants should be restricted to being a
.
EDITS:
[32:15] Replace text of constraint with
"A may appear only as a in a
DATA statement."
SUBMITTED BY: Malcolm Cohen
HISTORY: 99-275 m151 submitted
99-275r1 m151 approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
We considered Kurt's comments and decided no action was required.
NUMBER: 000083
TITLE: Scope of array-constructor implied-DO variable
KEYWORDS: Scope, implied DO, array constructor
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
14.1.3 states that the scope of an implied-DO variable in an array constructor
is "the implied-DO list". There is no such syntax term: what is meant?
In particular, in the array constructor
(/ (I,I=1,I) /)
are all three I's references to the implied-DO variable, or is one of them
a reference to a variable I in the enclosing scoping unit?
ANSWER:
All occurences of I within the implied-DO are references to the implied-DO
variable, none of them can reference a variable in the enclosing scoping unit.
The term "implied-DO list" is confusing in this context; "implied-DO" was
intended. An edit is supplied for clarification.
DISCUSSION:
The term "implied-DO list" is used in several places where the context is
that of the values produced by the implied-DO. This is an inappropriate
term to use for specifying scope.
Also, the second and third occurrences of "I" in the example shown are part of
the syntax item . It would be unreasonable to read
"implied-DO list" as meaning (for array constructors) " and the
in but not the s in
."
Note that the problem does not arise for because variables
other than implied-DO variables are not permitted in the limit expressions.
With this interpretation the example array constructor supplied is not valid
Fortran, as it is not permissible to reference the value of an
variable in one of its limit expressions.
EDITS:
[280:41] Replace "implied-DO list" with "implied-DO".
SUBMITTED BY: Malcolm Cohen
HISTORY: 00-124 m152 Submitted
00-124r1 m152 approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
Passed with no comments.
NUMBER: 000084
TITLE: Events that cause variables to be defined
KEYWORDS: Definition status, INTENT(OUT)
DEFECT TYPE: Erratum
STATUS: Passed by J3 letter ballot
QUESTION:
Item (6) of 14.7.5 says
"A reference to a procedure causes the entire dummy argument to become
defined if the entire corresponding actual argument is defined with a value
that is not a statement label.
A reference to a procedure causes a subobject of a dummy argument to become
defined if the corresponding subobject of the corresponding actual argument
is defined."
For an INTENT(OUT) dummy this appears to conflict with 14.7.6 item (13)(b)
"When a procedure is invoked ...
(b) A dummy argument with INTENT(OUT) is undefined except for any nonpointer
direct components of the argument for which default initialization is
specified."
So in
X = 3
CALL S(X)
...
SUBROUTINE S(A)
INTENT(OUT) A
...
Is A defined (with the value 3) in accordance with 14.7.5, or undefined in
accordance with 14.7.6?
Similarly, for subobjects of INTENT(OUT) dummies, does 14.7.5 take precedence
or 14.7.6?
ANSWER:
A is undefined in accordance with 14.7.6. An edit is supplied to remove the
conflict. Similarly, 14.7.6 takes precedence for subobjects.
EDITS:
To Fortran 95:
[289:9] Before "entire"
insert "dummy argument does not have INTENT(OUT) and the".
[289:12] Before "corresponding"
insert "dummy argument does not have INTENT(OUT) and the".
To draft Fortran 2002:
No edits required (above fixes already incorporated).
SUBMITTED BY: Malcolm Cohen
HISTORY: 00-141 m152 submitted, approved uc
00-209 m153 passed by J3 letter ballot
-------------------------------------------------------------------------------
J3/00-209
Page 12 of 12