From jkr@jkr.cc.rl.ac.uk Fri Jun 30 16:32:01 2000 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id QAA12988 for ; Fri, 30 Jun 2000 16:32:01 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id PAA14216 for ; Fri, 30 Jun 2000 15:32:00 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id PAA03824 for SC22WG5@dkuug.dk; Fri, 30 Jun 2000 15:33:03 +0100 (BST) Date: Fri, 30 Jun 2000 15:33:03 +0100 (BST) From: John Reid Message-Id: <200006301433.PAA03824@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: WG5 letter ballot on Fortran 95 interpretations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5 members, Enclosed in the first WG5 letter ballot on Fortran 95 interpretations. This will also be document N1390. The rules we operate on say: 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000067 Writing zeros --- --- 000068 Asterisks as I/O units --- --- 000069 What is a numeric character? --- --- 000070 Asymmetry between constant specification and initialization expressions --- --- 000071 Character array constructors --- --- 000072 Resolving generic procedure references --- --- 000076 INTENT(IN) dummy arguments and implied DO loops --- --- 000077 INTENT(IN) dummy arguments and NULLIFY --- --- 000079 Pointer Assignment and Allocatable Arrays --- --- 000080 Host association and the EXTERNAL attribute --- --- 000082 Usage of BOZ literal constants --- --- 000083 Scope of array-constructor implied-DO variable --- --- 000084 Events that cause variables to be defined The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above "yes" or "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to sc22wg5@dkuug.dk ------------------------------------------------------------------------------- NUMBER: 000067 TITLE: Writing zeros KEYWORDS: list-directed output, namelist output DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot The standard currently requires a real zero to be written in exponential form when using list-directed or namelist output. QUESTION: Is this requirement intentional or an oversight? ANSWER: The requirement is an oversight. DISCUSSION: The G edit descriptor was changed in Fortran 90 to format a real zero as if an F edit descriptor were provided in most cases. The same change was not made for list-directed or namelist output, but should have. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 10.5.4.1.2, 10.8.2, and 10.9.2.1 EDITS: [3:32+] In section 1.5.1, add the following as list item (3): (3) List directed and namelist output statements produce a real constant zero for a real value that is zero, and for the real or imaginary part of a complex value that is zero. In Fortran 95, these real constants are produced with the effect of an F edit descriptor, instead of an E edit descriptor. [4:24+] In section 1.5.2, add the following as list item (7): (7) List directed and namelist output statements produce a real constant zero for a real value that is zero, and for the real or imaginary part of a complex value that is zero. In Fortran 95, these real constants are produced with the effect of an F edit descriptor, instead of an E edit descriptor. [177:41] In section 10.8.2 (List-directed output), fifth paragraph, change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" [182:33] In section 10.9.2.1 (Namelist output editing), third paragraph, change "If the magnitude x is within this range" to "If the magnitude x is within this range or is zero" SUBMITTED BY: Robert Corbett HISTORY: 99-193 m150 Submitted 99-213r1 m150 approved uc 00-210 m153 Passed by letter ballot ------------------------------------------------------------------------------- NUMBER: 000068 TITLE: Asterisks as I/O units KEYWORDS: Asterisk, I/O, unit DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot Question: 1. Does the Fortran 95 standard require the external unit corresponding to the I/O unit identified by an asterisk for input or output to be the same as the external unit identified by some fixed nonnegative integer value? 2. Can the I/O unit identified by an asterisk for input or output correspond to more than one external unit? 3. If the external unit identified by an integer value that corresponds to the I/O unit identified by an asterisk for input or output is closed, does that cause the I/O unit identified by an asterisk to become disconnected? Answer: 1. No. 2. No. 3. Yes. Discussion: The submitter states: At least one Fortran 95 implementation uses -1 as the value of the I/O unit identified by an asterisk. A carefully constructed INQUIRE statement can expose this value to the user. Many users expect I/O to the units identified by asterisks to continue to work even after the corresponding units identified by integer values have been closed. 1. There is no requirement in the standard that the asterisk correspond to an external-file-unit. 2. For the units identified by the asterisk, the text of section 9.3.2 does not allow two or more units to be connected simultaneously to the same external device or file [139:8-9]. An edit is supplied to clarify this situation. 3. There might not be an external-file-unit that corresponds to the io-unit specified by an asterisk, as clarified by the edit below. If there is, it is permissible to execute a CLOSE statement on them as on any other unit. REFERENCES: ISO/IEC 1539-1:1997(E), Sections 9.3 and 9.4.4.2 EDITS: Add the following text to the end of the last paragraph before section 9.3.1 [138:34+]: "An asterisk used in an input statement may identify the same as a particular . An asterisk used in an output statement may identify the same as another particular ." SUBMITTED BY: Robert Corbett HISTORY: 99-192 m150 Submitted 99-215r1 m150 approved uc 00-208 m153 passed by J3 letter ballot ------------------------------------------------------------------------------- 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: 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 SUBMITTED BY: Robert Corbett HISTORY: 99-191 m150 Submitted by Robert Corbett 99-214 m150 J3 draft response, approved uc 00-209 m153 passed by J3 letter ballot ------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Asymmetry between constant specification and initialization expressions KEYWORDS: Initialization expressions; specification expressions DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the following programs. PROGRAM P1 REAL :: B = 4.0*ATAN(1.0) PRINT *, B END PROGRAM P1 PROGRAM P2 INTEGER :: A(INT(4*ATAN(1.0))) = 17 PRINT *, A END PROGRAM P2 According to 7.1.6.1 program unit P1 is not standard-conforming because of the reference to the intrinsic function ATAN which is not permitted in an initialization expression. According to 7.1.6.2 program unit P2 is standard-conforming; the reference to the intrinsic function ATAN is allowed by item (8) in the definition of a restricted expression. Expressions in the array bounds of an initialized entity are only required to be constant specification expressions, not initialization expressions. Was it the committee's intent to permit ATAN to appear in the array bounds of an initialized entity but not in the initialization value? ANSWER: No, this was not the intent. These expressions should have been described as initialization expressions instead of as constant expressions. This error also occurs for the definitions of an automatic entity, common block definitions and component definitions. The edits below change all of these to require initialization expressions instead of constant expressions. EDIT: [39:15] Change "a constant specification" to "an initialization". {Fix array components.} [39:23] Change "a constant specification" to "an initialization". {Fix character string components.} [40:30] Change "a constant" to "an initialization". {Fix note.} [48:47-48] Change "may be a nonconstant expression provided the specification expression" to "shall be an initialization expression unless it". [49:1-3] Delete "If a ... nonconstant expression." [49:4-5] Change "such a nonconstant expression" to "a that is not an initialization expression". {Fix definition of "automatic object".} [49:9] Change "a nonconstant expression" to "an expression that is not an initialization expression". {Fix evaluation time for character length.} [51:33] Change "a constant specification" to "an initialization". {Fix statement function character lengths.} [54:33] Change "nonconstant specification" to "not initialization". {Fix automatic array definition.} [54:34] Change "nonconstant specification" to "not initialization". {Fix evaluation time for explicit-shape array bounds.} [54:36] Change "the specification" to "any bounds". [56:32] Change "nonconstant specification" to "not initialization". {Fix evaluation time for assumed-size array bounds.} [56:34] Change "the specification" to "any bounds". [69:3-4] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix common block array-specs.} [192:26] Change "a constant" to "an initialization". {Fix characteristics of function results.} SUBMITTED BY: Henry Zongaro HISTORY: 99-178 m150 submitted 99-216r1 m150 approved uc 00-133 m152 additional edit, approved uc 00-208 m153 Passed by J3 letter ballot ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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." SUBMITTED BY: Malcolm Cohen HISTORY: 99-223 m150 submitted, approved 6-4 00-209 m153 passed by J3 letter ballot ------------------------------------------------------------------------------- NUMBER: 000080 TITLE: Host association and the EXTERNAL attribute KEYWORDS: Host association, EXTERNAL DEFECT TYPE: Erratum STATUS00-208.txt: 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 ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- 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: [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". SUBMITTED BY: Malcolm Cohen HISTORY: 00-141 m152 submitted, approved uc 00-209 m153 passed by J3 letter ballot -------------------------------------------------------------------------------