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