PC file: 94-006a3.0 Archive: 94-006r3.A0 -------------------------------------------------------------------------------- NUMBER: 00000b TITLE: Minor edits and corrections for Technical Corrigendum #2 KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: ANSWER: REFERENCE: EDITS: 1. 11.3.3.7, in the second sentence [161:16], change "C.11.5" to "C.11.4" 2. Annex A, host association [257:29]; Change "11.2.2" to "12.1.2.2.1". 3. Annex C, first example [273:14]; change "ENDTYPE" to "END TYPE". 4. Page 250, section 14.7.5, item (8) change 'input/output IOSTAT= specifier' to 'IOSTAT= specifier' Reason: 'input/output' is redundant. [250:24] HISTORY: m124 Submitted Feb 1993, papers 93-036, 93-078, 93-081 93-111 m125 X3J3 ballot approved items 1-3 94-034 m128 X3J3 ballot approved 4 (as part of 00000c, then moved here) 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: ANSWER: REFERENCE: EDITS: 5. Page 245, section 14.1.2.5, in the second sentence [245:3] change 'It' to 'Outside the type definition, it'. Reason: a component name appears in the derived type definition as well as possibly appearing in a component of a structure of that type. 6. In 13.13.42 IBITS, Result value, change '.... bit POS right-adjusted' to '.... bit POS, right-adjusted' [210:23] Rationale: it is the result, not POS, that is right-adjusted. 7. In 4.3.1 Numeric Types delete the last sentence "In this standard..." [27:2-3] Rationale: this is a not quite accurate restatement of R306 in section 3.2.3. ("unsigned" is not defined for boz numeric constants) SUBMITTED BY: HISTORY: 93-289 m127 submitted items 4-5 94-034 m128 X3J3 ballot item 4 approved (moved to 00000b), 5 failed 94-028 m128 additional items 6-7 94-028r1 m128 approval of items 6-7 uc 94-084 m128 correction of item 5, approved uc 94-116 m129 X3J3 ballot items 5,6,7 approved 21-2 -------------------------------------------------------------------------------- NUMBER: 00000d TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: ANSWER: REFERENCE: EDITS: 10. Page 339, section D.2.3 [339:3], add after the line for "'" ' " R408 R409 R410 R420' Rationale: Terminal symbol " was omitted from list 11. Section 7.2.3., first sentence [85:2] Change "operator" to "operation". 12. Section 10.9.1.2., first sentence [152:23] After "" add "(10.9)" 13. Annex A, [255:42] Change "CASE" to "SELECT CASE" 14. Section C4.3 [266:17] Change "KIND" to "kind". 15. Section C10 [281:5] Change "an apostrophe edit descriptor" to "a character constant edit descriptor delimited with apostrophes" 16. Section C10 [281:6-7] Change "the apostrophe edit descriptor" twice to "the edit descriptor" Rationale: for 15 and 16: In section 10 the term "apostrophe edit descriptor" is absent (see 10.2.1 and 10.7.1) 17. Section C13.1.6.3 [294:39-42] Delete word: "Declared" (4 times) Rationale: In section 13 descriptions of these functions do not contain the word "declared". These array inquire functions allow certain properties of an array to be determined dynamically. SUBMITTED BY: HISTORY: 94-165 m129 submitted item 10, approved u.c. 94-161r2 m129 submitted items 11-17, approved u.c. -------------------------------------------------------------------------------- NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so as to note complicate voting on edits and corrections that are being considered. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. REFERENCE: EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 -------------------------------------------------------------------------------- NUMBER: 000001 TITLE: Optimization of Fortran programs KEYWORDS: expression - arithmetic, mathematical equivalence, numeric operations, optimization DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Given a fragment such as 10 SUM = A + B 20 D = SUM + C does the standard allow the processor the freedom to replace this two statement fragment with any of the following single statements: 100 D = (A + B) + C 110 D = A + (B + C) 120 D = (A + C) + B 130 D = (B + A) + C 140 D = C + (B + A) ANSWER: The Fortran standard grants to processors an unlimited freedom to reorganize and modify programs, provided only that the execution "fulfills the interpretations herein" (1.4). In sections 7.1.7.1, 7.1.7.3, and elsewhere, specific additional freedoms are granted processors in expression evaluation. Generally speaking, all of these freedoms support what is called "optimization", the altering of the program in some way that is thought to improve a specific property, often performance, of the program. In this particular case SUM, in statement 20, is not an expression, but a reference to the result of a previous assignment. The additional freedoms granted for expression evaluation do not apply. Thus only those processors that can make the replacement and still "fulfill the interpretations herein" are permitted to do so. For these processors the answer is yes, for all other processors the answer is no. The "interpretation herein" is that SUM is a primary (7.1.1.1) of the expression "SUM + C" and the reference to SUM requires its value (Section 6, first paragraph). The determination of SUM's value was specified by assignment statement 10. The result of that assignment, with its possible conversions of "A + B" to the type and type parameters of SUM, is the value of SUM. This is the interpretation that must be fulfilled by conforming processors. A common optimization for this fragment is to replace it by statements such as 100, 130, etc. where the calculation of A + B appears in parenthesis. This replacement corresponds to the calculation of A + B in a temporary location (i.e., a register) and then accessing that temporary location instead of storing the result in SUM and then accessing that stored value. REFERENCE: EDITS: None. SUBMITTED BY: J. C. Adams 119-JCA-2 (119.002) HISTORY: 119-RL-1 (119.047) 92-044 S20.120A 92-104 Interpretation 92-147 m122 approved by a vote of 21-1 92-267r m123 Edit approved Comments Accompanying Ballots on N865, Munchhausen, Rolison and Shen N881 WG5 approved. However ballot comments led X3J3 to reconsider 93-132 m125 approved 18-4 93-255r1 m127 ballot failed 23-1 94-026r1 m128 proposed response (using 'freedom') 94-025r1 m128 proposed response (using 'freedoms') approved 17-2 94-116 m129 X3J3 ballot approved 22-1 -------------------------------------------------------------------------------- NUMBER: 000004 TITLE: Blanks in format specifications in free form source KEYWORDS: source form - free, i/o format specification, blanks DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following format specification valid in free form source? FORMAT (B N) ANSWER: Yes. Discussion: Sections of Fortran 90 are not consistent. 3.3.1: In free form, blank characters must not appear within lexical tokens other than in a character context. and A blank must be used to separate names, constants, or labels from adjacent keywords, names, constants, ... 10.1.1: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor. It can be seen that the text in chapter 3 does not consider edit descriptors. The text will be revised so that: -- blanks are allowed in edit descriptors. These changes are desirable because format specifications are conceptually their own sub-language, where the components thereof are not affected by the source form of the containing procedure and are not subject to most other syntactic rules. Thus, the rules concerning blanks in keywords do not apply to edit descriptors in format specifications. This treatment of format specifications is desirable so that "run-time formats" can be processed independently of the source form of the procedure containing a data transfer statement. In the absence of these changes, some standard conforming subprograms would not constitute a standard conforming Fortran 90 program, depending on which source form OTHER subprograms were written in. For example, consider a character variable containing a format specification which was passed to a subprogram where the variable was used in an I/O statement. In a standard conforming subprogram, this format specification could contain embedded blanks within an edit descriptor (i.e. "(B N, I5)"). If this variable is then passed to another subprogram, which uses it as a format in a data transfer statement, then the validity of the entire program would depend on which source form the called subprogram was written in. EDIT: Section 3.3.1, second paragraph [22:6], change "... character context." to "... character context or in a format specification." SUBMITTED BY: J. T. Martin 119-JTM-2 (119.015) HISTORY: 119-JTM-2 119-RPK-1 92-044 S20.120, number 4 92-075 92-145 Draft Interpretation by CIO, withdrawn 92-176 m122 by approved uc 92-326 ballot comments (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved; accept Martin edits 94-160 m129 WG5 ballot, failed 94-174r2 m129 elaborated discussion, removed first and second edit; approved 21-0 -------------------------------------------------------------------------------- NUMBER: 000007 TITLE: Duplicate module procedures in interface blocks KEYWORDS: module procedure name, interface block, generic name, MODULE PROCEDURE statement DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: May a module procedure name be referenced on more than one MODULE PROCEDURE statement for a given generic name in a scoping unit, either in a single interface block or in multiple interface blocks specifying that generic name? Section 12.3.2.1 indicates: "A procedure must not have more than one explicit specific interface in a given scoping unit." ANSWER: No. Discussion: The standard routinely disallows such redundant specifications within a scoping unit. The prohibition for this case was inadvertently overlooked. This deficiency is remedied by the supplied edit. A MODULE PROCEDURE statement does not specify the explicit interfaces of the module procedure names, so the text referenced from 12.3.2.1 does not apply. Example: INTERFACE INT_1 MODULE PROCEDURE FOO, FOO ! second FOO is illegal MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 ! FOO1 is illegal here END INTERFACE INT_1 INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INT_2 INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C ! FOO2B is illegal here END INTERFACE INT_2 REFERENCES: ISO/IEC 1539:1991(E) Section 12.3.2.1 EDIT: The following additional constraint should be added to section 12.3.2.1 [167:36]: Constraint: A in a must not be one which previously had been specified in any with the same generic identifier in this specification part. SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) HISTORY: 120-MBSH-4A (120.096A) Original interpretation 92-039 Adopted because this interpretation is more consistent with requirements concerning duplication of other specification statements in a given scoping unit. 92-095 modification WG5/N786A Commented on, Victoria meeting, item marked 1167/36+. 92-155A m122 approved uc 94-034 m128 X3J3 ballot failed 25-3 94-093 m128 alternate answer proposed, approved uc 94-116 m129 X3J3 ballot failed 15-8 94-197r1 m129 revised discussion and edit, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000008 TITLE: subsumed by 000007 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: REFERENCES: 120-MBSH-4A (120.096A) EDITS: SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) item 5, question 4 HISTORY: Interpretation questioned in X3J3/92-039 Resolved by X3J3/92-155A (approved by unanimous consent as the response to NUMBER 000007) subsumed by 000007 -------------------------------------------------------------------------------- NUMBER: 000011 TITLE: Multiple accessible defined operator and assignment interfaces KEYWORDS: interface block, defined assignment, defined operator DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following excerpts from section 14.1.2 [241]: Excerpt (a): Within a scoping unit, entities in the following classes: (1) Named variables that are not statement entities (14.1.3),..., generic identifiers, derived types, and namelist group names ... are local entities of that scoping unit. Excerpt (b): Within a scoping unit, a name that identifies a local entity of one class must not be used to identify another local entity of the same class, except in the case of generic names (12.3.2.1). A name that identifies a local entity of one class may be used to identify a local entity of another class. The standard defines both the terms "generic identifier" and "generic name" in section 12.3.2.1 [168]. "Generic identifier" is defined to encompass the three concepts of a generic name, a defined operator, or an equals symbol on a generic specification. "Generic name" refers to the BNF term for the name that may appear on an interface specification. The text from section 14 cited in (a) uses the term "Generic identifier" but the text cited in (b) uses the term "generic name". Is the intent behind the choice of different words in section 14 to prohibit a program from containing multiple interface blocks for the same operator and multiple accessible defined assignment interfaces? ANSWER: No. Discussion: Section 11.3.2 states: "If two or more generic interfaces that are accessible in a scoping unit have the same name, the same operator, or are both assignments, they are interpreted as a single generic interface" Thus, two or more interfaces that have the same name, the same operator, or are assignment interfaces are not only permitted but the interfaces are considered to be a single generic interface. The text cited in (b) above was specifically discussing "names" and hence "generic names" were singled out. The text cited in (a) above was discussing all entities that are local to a scoping unit, not just named entities. EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-4 (120.029), question 3 HISTORY: 120-MBSH-1A (120.084A) Originally passed as m123 Revised in response to ballot comments but no vote taken - withheld for further consideration 93-029 Slight rewording for clarification m124 Approved unanimous consent 93-111 m125 X3J3 ballot approved with Rolison edits 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000012 TITLE: Type of a named constant when there is implicit mapping KEYWORDS: named constant, PARAMETER statement, implicit mapping DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 5.2.10 states: "The named constant must have its type, shape, and any type parameters specified either by a previous occurrence in a type declaration statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." Question 1: It is not clear what is meant by the phrase "the implicit typing rules currently in effect" Note that this phrase also appears in sections 7.1.6.2 and 5.4. Does this mean that more one implicit mapping can exist in a scoping unit? Are the following code fragments valid Fortran 90? Example 1. PARAMETER (A=1) IMPLICIT INTEGER (A) Example 2. PROGRAM MAIN IMPLICIT INTEGER (Z) ! Z is mapped to type integer ... CONTAINS SUBROUTINE INNER PARAMETER (ZERO = (0.0, 0.0)) ! Name starts with Z IMPLICIT COMPLEX (Z) ! Z is mapped to type complex ... END SUBROUTINE END PROGRAM Question 2: The statement in section 5.2.10 seems inconsistent in that the program unit SUBROUTINE SUB ( ) REAL, DIMENSION (2) :: R PARAMETER (R = 1) END appears to be valid, while the program unit SUBROUTINE SUB ( ) DIMENSION R(2) PARAMETER (R = 1) END does not appear valid. Was it intended that one case be valid while the other is not? ANSWER: Answer 1: No in both cases. In each scoping unit there is a single mapping. The code fragments are not valid. Answer 2: No, that was not the intent; both program units are valid. Discussion: Section 5.3 (IMPLICIT statement) states: In each scoping unit, there is a mapping, which may be null, between each of the letters A,B, ...Z and a type (and type parameters). The reference to the singular "a mapping" is intended to convey that in each scoping unit there is a single mapping. Unfortunately the phrase "the implicit typing rules currently in effect" may give the impression that more than one mapping can exist. This is an error which is corrected by the edits specified below. Section 5.2 states: The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification. Section C.5.1 also supports this intent. Thus there is evidence in the standard that the same restrictions should be applied to objects independent of whether their attributes were specified in a type declaration statement or an attribute specification statement. An edit below clarifies this intent. EDITS: 1. In section 5.2.10 change the second paragraph to: [53:43-47] "The named constant must have its type, type parameters, and shape specified in a prior specification of the or declared implicitly (5.3). If the named constant is typed by the implicit typing rules, its appearance in any subsequent specification of the must confirm this implied type and the values of any implied type parameters." 2. In section 5.3 in line 3 of the paragraph that starts with "Any data entity that is" after 'not null.' and before the Corrigendum 1 addition [54:35], add: "The mapping for the first letter of the data entity must either have been established by a prior IMPLICIT statement or be the default mapping for the letter." 3. In section 5.4 in the penultimate paragraph [56:22-24]: in line 3, delete "currently" and in lines 4-5 replace "this implied type" by "the implied type and type parameters". 4. In section 7.1.6.2, in line 2 of the paragraph after the constraint [79:23] delete "currently". SUBMITTED BY: (Question 1) J. T. Martin, 120-JTM-9 (120.046), question 3 (Question 2) Jon Steidel, 120-JLS-2 (120.020) case 3 HISTORY: 120-LJM-5 (120-093) 92-172 m122 modified, passed 12 subsumes 23 following letter ballot 93-73r2 m124 adopted uc 93-111 m125 ballot approved with Rolison edits 93-150 m125 edits 93-227r1 m126 revised to make 12, 114 and 134 consistent, edit added, approved uc 93-255r1 m127 ballot failed 19-5 m127 12 subsumes 114, 134 93-328 m127 response 94-050 m128 revised edits, approved uc 94-116 m129 X3J3 ballot approved 22-1 -------------------------------------------------------------------------------- NUMBER: 000023 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Jon Steidel, 120-JLS-2 (120.020) case 3 HISTORY: 120-LJM-5 (120-093) Response in X3J3/92-172, must be identical to response to item 000012 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for pointers and target association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: Any of the above conditions except for f) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. In determining whether a pointer and a target are associated, the bounds are not relevant, but the extents are. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). If none of the conditions stated above, except possibly f) are true, but TGT is zero sized, the result of ASSOCIATED (PTR, TGT) is undefined. Discussion: There are only three means by which a pointer may become pointer associated: via the ALLOCATE statement (6.3.1), via pointer assignment (7.5.2), or via argument association (12.4.1.1). -- In an ALLOCATE statement, the object created inherits its type, type parameters, rank, shape, size and bounds from those declared for, or specified with, the pointer name. -- In a pointer assignment, the type, type parameters, and rank of the pointer and target must conform, and the shape, size, and order of elements of the target determine those of the pointer. -- When a pointer actual argument is passed to a pointer dummy argument, the pointer dummy argument becomes pointer associated with the same target as the pointer actual argument. In all three of these cases, array elements of the pointer and the target correspond with one another in array element order. Thus, since there is no other way for two objects to become pointer associated, their type, type parameters, rank, size, shape, and order of elements must be the same. REFERENCES: ISO/IEC 1539:1991 (E) 5.1.2.4.3, 6.3.1, 7.5.2, 12.4.1.1, & 14.6 EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022) HISTORY: 120-LJM-3A (120.081A) m121 Original response proposed 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 92-093A m121 Approved 92-329 (jw note) m123 Approval rescinded at m123 (uc) 93-099r1 m124 Revised response adopted (15-2) 93-111 m125 ballot failed, returned to subgroup 93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. 93-255r1 m127 ballot failed 17-7 -------------------------------------------------------------------------------- NUMBER: 000028 TITLE: Host association and Implicit type rules KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION 1: Consider the following program fragment: MODULE A CONTAINS SUBROUTINE B(Z) IMPLICIT INTEGER (X) 10 Z = XXX !Local variable or invalid function reference? ... END SUBROUTINE REAL FUNCTION XXX() ... END FUNCTION END MODULE In the above example in statement 10, is XXX an implicitly typed scalar variable or an erroneous function reference to module procedure XXX? That is to say, does the syntax of the reference determine which entity is referenced? QUESTION 2: Consider the following program fragment: MODULE X INTEGER, DIMENSION(10) :: A ... CONTAINS SUBROUTINE Y() ... CONTAINS SUBROUTINE Z(I) 20 A(I) = I ! Host associated array reference ! or invalid reference to function A? END SUBROUTINE FUNCTION A(K) ! Hides array A in module spec part? ... END FUNCTION END SUBROUTINE END MODULE Is the reference to A in statement 20 a reference to the array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER 1: The reference to XXX is an invalid reference to the host associated module procedure XXX. The syntax of the reference does not determine which entity is referenced. ANSWER 2: The reference to A is an invalid reference to the host associated internal procedure A. Discussion: Section 5.3, in the fourth paragraph beginning "Any data entity ...", defines which data entities are implicitly typed. This definition excludes variables made accessible by use association or host association. In the first example, a form of reference does not differentiate between a host associated entity and a local implicitly typed scalar. In the second example, within subroutine Y the definition of the internal procedure A makes the array A inaccessible by host association (section 12.1.2.2.1). The internal procedure A is accessible within subroutine Z by host association. The reference to A(I) in subroutine Z is an invalid reference to function A. REFERENCES: EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ui 105 ballot comments (jw note) 93-134 m125 unanimous consent 93-255r1 m127 ballot failed 23-1 93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, approved u.c 94-116 m129 X3J3 ballot failed 16-7 94-164 m129 clarify question and answer, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000029 TITLE: Class of a defined operator KEYWORDS: defined operator, generic identifier, local entities - classes of DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Is a defined operator name a generic identifier? Thus is it illegal for a defined operator name to be the same as another class 1 entity within the same scoping unit (as defined in 14.1.2)? ANSWER: The word 'name' is used in a technical way throughout the standard. It is defined by R304 on page 19 and is not used in the definition of by R311, R704, R724 on page 21. A defined operator is a generic identifier (see page 168, lines 12 and 11 from the bottom), but it does not have a name. Therefore the rule in 14.1.2 does not apply. This is analogous to the situation for intrinsic operators, where it is permissible to have local variables named AND, OR, etc. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.2.2, 3.2.4, 12.3.2.1, 14.1.2 EDIT: None. SUBMITTED BY: Jon Steidel, 120-JLS-7 (120.025) HISTORY: 120-RL-2A (120.059A) 121-LRR-8 Opposed to 121-JKR-2 121-JKR-2 Opposed to S20/29 (120-59a) 92-106 Interpretation based on 121-JKR-2 92-148A m122 Approved by unanimous consent 92-252 m124 Approved by unanimous consent 93-111 m125 ballot approved with Weaver edit 94-160 m129 WG5 approved with Rolison edit 94-169 m129 Rolison edit -------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor DEFECT TYPE: Erratum STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, ac- value is defined to be an expr or an ac-implied-do. Since an ac-value may be an expression, a substring is a valid ac-value. Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other ac-value in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1. is yes. Each character literal constant in an must be the same length. Both examples are nonstandard conforming. The answer to question 3. is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an . Since the length cannot always be determined at compile time, the constraint must be changed to prose. EDITS: 1. Delete the second constraint following R435. [38:3] 2. Add the following paragraph after the constraints in 4.5. [38:4] Each expression in the must have the same type and type parameters. SUBMITTED BY: (Questions 1 and 2) Larry Rolison in 120-LRR-1 (120.026) (Question 3) Larry Rolison in X3J3/93-070 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - 93-070 m124 Question 3. submitted as 93-100 m124 proposed response, adopted by unanimous consent 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot, failed; 94-179 m129 minor edit changes -------------------------------------------------------------------------------- NUMBER: 000033 TITLE: Interface blocks with the same name in a program KEYWORDS: generic interface, module, USE statement DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Question 1: In the following program, both interface blocks have the same generic name and thus might be considered to be merged into a single generic interface block. Is function F1 (from module MOD_1) accessible to the program but function F2 (from module MOD_2) hidden? MODULE MOD_1 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface - PUBLIC. INTEGER FUNCTION F1(K) INTEGER K END FUNCTION END INTERFACE ... END MODULE MOD_1 MODULE MOD_2 PRIVATE INT_1 INTERFACE INT_1 ! Generic interface, same name - PRIVATE INTEGER FUNCTION F2(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_2 PROGRAM EXAMPLE_1 USE MOD_1; USE MOD_2 ! Program accesses both modules. ... END Question 2: If the following module is added to the above example and the USE statement in the main program is changed to "USE MOD_1; USE MOD_2; USE MOD_3", is the resulting program standard conforming? MODULE MOD_3 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface, same name - PUBLIC. INTEGER FUNCTION F3(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_3 Question 3: If the program and modules shown above are altered so that module MOD_2 USEs MOD_1 and the program EXAMPLE_1 only USEs MOD_2 directly, is this an example of a standard conforming program? If it is standard conforming, does the program have access to function F1 but not F2? ANSWER 1: No. Function F2 is still accessible but only by its specific name. ANSWER 2: Yes, but not for the reason implied by the question. ANSWER 3: Yes. The program will have access to functions F1 and F2 but only by their specific names. Discussion: Because the name INT_1 is private in the module MOD_2, the interface for the function F2 is accessible in the program EXAMPLE_1, but NOT the generic name INT_1. Therefore, the two interface blocks are NOT merged into a single generic interface block. The function F1 is, therefore, accessible in the program EXAMPLE_1 by either its specific name F1 or the generic name INT_1; the function F2, on the other hand is accessible only by its specific name F2. This shows that the function F2 (from module MOD_2) does not share the same generic name, INT_1, as the function F1 (from module MOD_1). When the example is modified as specified by Question 2, the new module MOD_3 defines a new interface block INT_1, which will be combined with the identically named interface block from module MOD_1. In the program EXAMPLE_1 the generic name INT_1 has the two specific names F1 and F3. However, since F2 is not part of the combined generic interface block the fact that F2 and F3 have the same dummy argument and result characteristics is of no significance, and the program is standard conforming. When the example is modified as specified by Question 3, within module MOD_2 the two generic interface blocks are combined into a single interface block. However, since INT_1 is declared to be private within module MOD_2 only the specific names of the functions F1 and F2 are accessible to program units using MOD_2. Therefore, both the function F1 and F2 are accessible within the program EXAMPLE_1, but only by their specific names. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.3, 11.3.2 EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) HISTORY: 120-TMRE-3 (120.076) Included into S20 as three items (33-35). Recombined in 92-308. Revised in response to ballot comments in 93-082. m124 Approved by unanimous consent 94-160 m129 WG5 ballot approved with edit request from Japan 94-168 m129 WG5 requested edit to answer 3. -------------------------------------------------------------------------------- NUMBER: 000034 TITLE: subsumed by 000033 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) Part 2 HISTORY: 120-TMRE-3 (120.076) subsumed by 000033 -------------------------------------------------------------------------------- NUMBER: 000035 TITLE: subsumed by 000033 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Larry Rolison, 120-LRR-6 (120.031) Part 3 HISTORY: 120-TMRE-3 (120.076) subsumed by 000033 -------------------------------------------------------------------------------- NUMBER: 000039 TITLE: Association of a pointer actual argument with a dummy argument KEYWORDS: pointer, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: When a pointer is passed as an actual argument, is the intent of the standard as follows: Dereferencing of the pointer is dependent on the interface of the called procedure. That is, if the dummy argument is known to be a pointer (with matching type, etc.) then the pointer actual argument is NOT dereferenced - the pointer itself is passed. Conversely, if the dummy argument is unknown or is known to not be a pointer then the pointer actual argument is dereferenced so that its target is passed (possibly through a temporary)? If yes, please quote the text that specifies the meaning of passing a pointer as an actual argument. ANSWER: Section 5.1.2.4.3 indicates that a pointer actual argument may be associated with either a pointer dummy argument or a nonpointer dummy argument. The semantics of a pointer actual argument associated with a pointer dummy argument are specified in section 12.4.1.1. When a pointer actual argument is associated with a nonpointer dummy argument, the actual argument's associated target object becomes associated with the dummy argument. Section 7.1.4.1 states: If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced. Discussion: The standard does not specify implementation details. A valid implementation would allow passing a descriptor when a pointer actual argument is associated with a pointer dummy argument and its target when the dummy argument is a nonpointer. Another valid implementation would be to pass a descriptor in both cases. Since the notion of referencing and dereferencing pointers is implementation dependent, the standard does not use these terms when discussing pointers and targets. The standard does state when a pointer's association status may change (pointer assignment, allocation, deallocation, nullification, and association with a dummy argument which is a pointer) and several cases where a pointer name refers to the associated target object (assignment as primary in an expression, and an I/O list). There is also an example of a pointer actual argument associated with a nonpointer dummy argument in section 12.5.2.9. The corrections indicated below clarify the rules and meaning of associating a pointer actual argument with a nonpointer dummy argument. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.3, 7.1.4.1, 7.5.1.5, 9.4.4.4, 12.4.1.1, & 12.5.2.9 EDITS: 1. Delete the penultimate (tenth) paragraph of 5.1.2.4.3, "A pointer dummy argument ... argument." [46:41-42] 2. Add the following new paragraph following the current fifth paragraph of section 12.4.1.1: [173:13+] If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. SUBMITTED BY: Larry Rolison, 120-LRR-9 (120.034) HISTORY: 120-JLS-9 (120.079) Passed letter ballot to move to "Ready for WG5" status 92-201 92-228 (jw note) 93-102 m124 Revised response adopted by unanimous consent 93-111 m125 ballot approved with Maine, Martin edits 93-150 m125 edits from X3J3 ballot 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with target dummy argument requires explicit interface KEYWORDS: argument - dummy, interface - explicit, TARGET attribute DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. It is true that requiring an explicit interface for a procedure with a dummy argument that has the TARGET attribute aids optimization of the subprogram that calls the procedure. Such an explicit interface also allows a processor to diagnose when an actual argument which does not have the TARGET attribute becomes associated with a dummy argument that has the TARGET attribute. The supplied edit corrects the error. Discussion: Section 6.3.3.2 states that upon execution of a RETURN or END statement, some pointers declared or accessed in the procedure retain their association status. For example, if a pointer is accessible to both the subprogram which references the procedure and the referenced procedure, or if the procedure is a function whose result has the POINTER attribute, such a pointer cannot become associated with an actual argument during execution of the procedure if the target actual argument becomes associated with a nontarget dummy argument. If a procedure does not have an explicit interface, a processor may assume any actual argument with the target attribute cannot become associated with such a pointer during execution of the procedure. Requiring an explicit interface for a procedure with a target dummy argument also allows the processor to diagnose association of a nontarget actual argument, such as an expression, with the target dummy argument. Note that edits in defect item 125 make the need for the explicit interface mandatory. EDIT: Section C.5.3, second sentence, change "solely" to "primarily". [269:21] SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) 92-070 m121 Approved m123 Approval rescinded (uc) 93-101 m124 Revised response adopted by uc 93-111 m125 ballot approved m128 Status changed to "consideration in progress" as this refers to edits in 000121 that no longer exist -------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: It was intended that only the mapping from program state to value be of significance, not the particular form in which that mapping is expressed. An edit to make this clear has been included. As the same phrase appears in section 12.2.1.1 an edit is also included for that section. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: 1. Replace the last two sentences in 12.2.2 [166:14-16] with the following: If the shape or character length type parameter is not constant, the corresponding characteristic is the method by which the value is to be determined when the function is invoked. This includes the possibility that the value is assumed or that it is given by evaluating a specification expression. Two such methods are considered to be the same if the following are true: (1) they yield the same value (2) if one involves the evaluation of variables then the other must involve the evaluation of the same storage units (although not necessarily the same variable names). 2. Replace the last two sentences in 12.2.1.1 [166:4-6] with the following: If the shape or character length type parameter is not constant, the corresponding characteristic is the method by which the value is to be determined when the procedure is invoked. This includes the possibility that the value is assumed or that it is given by evaluating a specification expression. Two such methods are considered to be the same if the following are true: (1) they yield the same value (2) if one involves the evaluation of variables then the other must involve the evaluation of the same storage units (although not necessarily the same variable names). SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, -------------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving generic procedure references KEYWORDS: generic name, interface block, intrinsic procedure DEFECT TYPE: Interpretation STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 92-048 pg 29-30, 34-40, 51, 52, One of the questions raised in 92-052 pg 1-3 One of the questions raised in 92-119 Initially drafted 92-157 m122 approved m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword DEFECT TYPE: Erratum STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: Is the use of "keyword" in 12.4.1 page 172 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2 page 16? In 13.10 page 188 is "keyword" the correct term (or should it be "argument keyword")? ANSWER: For each question, the answer is "NO". There are two different definitions of "keyword", 2.5.2 page 16 and 3.2.1 page 19. Neither definition is complete. The edits below combine these two definitions into one and consistently use "argument keyword" where appropriate. Note that edits 3 and 6 are related to edit 1 in item 4. EDITS: 1. Page 5, section 1.5.3, (3) [5:9] delete "keyword actual arguments and" rationale: these are not specifiers and -spec is not used with them. 2. Page 16, section 2.5.2, first paragraph, first occurrence [16:3] change "statement keyword" --------- ------- to "statement keyword (often abbreviated to keyword)" --------- ------- ------- rationale: define "keyword", in a style similar to "object" in 2.4.3.1. 3. Page 16, section 2.5.2, first paragraph, end of [16:5] add "Keywords appear as upper-case words in the syntax rules in Sections 4 through 12". 4. Page 16, section 2.5.2, second paragraph, first sentence [16:6] change "name." to "name (see 12.4.1)." 5. Page 19, section 3.2 [19:35] change "keywords" to "statement keywords (2.5.2)" 6. Page 19, section 3.2.1 [19:37-38] delete rationale: 2.5.2 is now the complete definition. 7. Page 160, section 11.3.3.5, first paragraph, third line [160:29] change "keywords" to "argument keywords" 8. Page 168, replace the second sentence of the paragraph following the line "END INTERFACE" [168:24] with "Invocations of these procedures may use argument keywords; for example:" rationale: "keyword calls" is not defined. In general invocations can use both positional and argument keywords. 9. Page 172, in the first paragraph following the constraints [172:13-17] change "a keyword" to "an argument keyword" twice, and change "the keyword" to "the argument keyword" 10. Section 13.3, first sentence [183:37], set "positional arguments" and "keyword arguments" in regular font 11. Page 183, section 13.3, first paragraph, third line [183:38] change "the keyword" to "the argument keyword" and change "A keyword" to "An argument keyword" 12. Page 188, section 13.10, first paragraph, first two lines [188:12-13] change "keyword" to "argument keyword" and change "keywords" to "argument keywords" 13. Page 363, delete the entry for "argument keywords 183" [363:37] rationale: odd to index both singular and plural. "Keyword", and "statement keyword" are indexed to page 16, as is the remaining entry for "argument keyword". 14. Annex F, delete the entry "positional arguments" [368:13] SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. 92-164A m122 approved 17-4 ballot comments, 92-326 (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved with Kelble edits m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit to that section (defect item 49) has clarified that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: In section 5.1.1.5 item (3), add to the end [43:5]: "Note that the interface for such a function cannot be specified in an interface body." SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in 0000049 referenced -------------------------------------------------------------------------------- NUMBER: 000071 TITLE: Use association and common block names KEYWORDS: use association, common block name, association - storage DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Can a module or subprogram access through use association variables declared in different modules to be in the same common block? Example: MODULE MOD1 COMMON /BLOCK/ A,B,C END MODULE MOD1 MODULE MOD2 COMMON /BLOCK/ X,Y,Z END MODULE MOD2 SUBROUTINE USER() USE MOD1 USE MOD2 ... Y = A ! Are both Y and A accessible? END ANSWER: Yes. Discussion: The COMMON statement in MOD1 forms a common block storage sequence as described in 5.5.2.1. The COMMON statement in MOD2 similarly forms a common block storage sequence. These two sequences are associated as described in 5.5.2.3, thus associating A with X, B with Y, and C with Z. The USE statements in USER make these variables accessible in that scoping unit. The associated variables are considered to behave as though they had been equivalenced. The list of entities made accessible by use association in 11.3.2 includes variables but not common blocks, so there is no implication that these two specifications of common block storage sequences for /BLOCK/ interfere with each other or require a concatenated common block storage sequence in USER. Various other combinations of use association, host association, and local COMMON statements can similarly result in common associated variables being accessible in the same scoping unit. One of these cases, that involve use association and local COMMON statements, is prohibited in 5.5.2.5. The edits below emphasize the independence of common block storage sequence formation from use and host association and eliminate the ineffective restriction in 5.5.2.5. EDITS: 1. In the first sentence of 5.5.2.1 after "For each common block", insert "in a scoping unit". [59:11] 2. At the end of 5.5.2.1, add the following paragraph: "Only COMMON statements and EQUIVALENCE statements appearing in the scoping unit contribute to common block storage sequences formed in that unit. Variables, in common blocks, made accessible by use association or host association do not contribute." [59:19] 3. At the end of the first paragraph of 5.5.2.3, add the following sentence: "Use association or host association may cause these associated objects to be accessible in the same scoping unit." [59:30] 4. Delete the last two sentences in 5.5.2.5. [60:19] SUBMITTED BY: Jon Steidel, 120-JLS-8 HISTORY: ui 97 (jw note) 120-86 (120-MBSH-3), initial response draft 92-163 revised draft response 92-191 revised draft response 92-316 revised draft response - approved (19-2) m123 93-087 consideration of ballot response: 92-316 reapproved by unanimous consent 93-111 m125 ballot, approved with Weaver and Rolison edits 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000073 TITLE: Description of the MERGE intrinsic function KEYWORDS: function - elemental, MERGE, array construction function DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTIONS: The MERGE intrinsic function is described as an array construction function in sections 13.8.6 and 13.10.16. The description of MERGE in section 13.13.67 classifies it as an elemental function. 1. Are the descriptions of MERGE in sections 13.8.6 and 13.10.16 consistent with its classification as an elemental function? Note that 13.8 is "Array intrinsic functions" and MERGE is the only elemental included. 2.Should all elemental functions be listed as "array construction" functions or should MERGE be described elsewhere? ANSWERS: 1. Yes. MERGE is both an elemental intrinsic function and, when called with array arguments, an array construction function. 2. All elemental intrinsic functions are array construction functions when called with array arguments. EDIT: None SUBMITTED BY: Dick Weaver X3J3/92-197 HISTORY: 92-197 Submitted 92-322 m123 Draft response (not approved) 93-090 Response in passed 14-4 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000075 TITLE: Interface blocks in block data KEYWORDS: interface block, BLOCK DATA program unit DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In section 12.3.2.1, on page 167, the third constraint "An must not appear in a BLOCK DATA program unit." is constraining what? (The existence of a constraint implies that, if the constraint were not present, the constrained "action" would be allowed.) ANSWER: The syntax rules for include which in turn includes . Although the constraint is redundant with the second constraint in section 11.4, the committee feels there is no harm in leaving this constraint intact as a reminder that an interface block must not appear in a block data subprogram. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-200 92-323 m123 Draft response, not approved 92-323 m124 reconsidered; reapproved uc 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved with Rolison edit 94-176 m129 Rolison edits as requested by WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000076 TITLE: Attributes, properties, characteristics KEYWORDS: data object, attribute, property, characteristics DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: The first paragraph of Section 5 states: Every data object has a number of properties (for example, type, rank, and shape) that determine the characteristics of the data and the uses of the object. Collectively, these properties are termed the attributes of the data object. Thus data objects have -- attributes -- properties -- characteristics (see also 12.2.1.1) Other sections of ISO/IEC 1539:1991 use these terms indiscriminately. What is the relationship between attributes, properties, and characteristics? Is this complexity, which seems to lead to a number of difficulties, necessary? ANSWER: In Section 5, the term "attribute" is used in a technical sense and the terms "property" and "characteristic" are used as "normal English" to help explain the meaning of "attribute". In Section 12, "characteristic" is given a technical definition. Thus the usage of the term "characteristic" is not consistent throughout ISO/IEC 1539:1991. There may be other sections of the standard that use these terms in an inconsistent fashion. These inconsistencies will be resolved in a revision of ISO/IEC 1539:1991. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 92-202r m123 Submitted along with suggested edits 92-248 A related question appears in 92-305 suggested edits 92-307 suggested edits 93-112r m125 Draft response, adopted 15-6 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000077 TITLE: Miscellaneous questions KEYWORDS: entity, data entity, data object, variable, external subprogram DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Question 1: In Annex A, the definition of the term "entity" should subsume the definition of the term "data entity". This is not the case. Is this a flaw? Question 2: In many places in the standard (in sections 2, 4, 7, 8, 9, and 13), the term "entity" (or "entities") is actually referring to "data entity" (or "data entities"). There are other places (in sections 6 and 9) where the term "entity" is used, that the term "variable" would be more precise. In section 9.1, the term "physical entity" is used in the ordinary English sense and this is inconsistent with the definition of "entity" in Annex A. In section 9.4.4.4, "namelist entity (10.9)" appears, but section 10.9 defines "name-value subsequences" which is the proper term. Should not the standard be more precise in usage of the term "entity"? Question 3: In sections 9.4.4.4 and 9.4.4.4.2, "data are transferred" appears. In these instances "data" is a collective noun and should be accompanied by a singular verb as the collection is taken as a unit. Should this phrase be changed to "data is transferred"? Question 4: In Annex A, should "subprogram" in the definition of "main program" be changed to "external subprogram" to be consistent with the definition for "program unit"? ANSWER: Answer 1: Yes, an edit below corrects this flaw. Answer 2 and 3: These questions will be addressed in the revision of ISO/IEC 1539:1991. Answer 4: Yes, an edit below makes this change. EDITS: 1. In Annex A, in the entry for "entity", replace "a named variable, an expression, a component of a structure, a named constant" with "a data entity". [256:38-39] 2. In Annex A, in the entry for "main program", replace "subprogram" with "external subprogram" [258:22] SUBMITTED BY: Dick Weaver HISTORY: 92-203 m123 Submitted along with suggested edits 93-113 m125 Draft response, adopted 18-1 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000079 TITLE: Automatic character and ALLOCATABLE, POINTER and TARGET attributes KEYWORDS: allocatable, automatic, character, POINTER attribute, TARGET attribute, array allocatable, array automatic DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 5.1 states: The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram. If the data object being declared depends on the value of such a nonconstant expression and is not a dummy argument, such an object is called an automatic data object. An automatic object must not appear in a SAVE or DATA statement nor be declared with a SAVE attribute nor be initially defined with an = . Thus, a character object with a length-selector which is a nonconstant type-param-value is an automatic object. Section 5.1.2.9 states: The ALLOCATABLE attribute specifies that objects declared in the statement are allocatable arrays. Such arrays must be deferred-shape arrays whose shape is determined when space is allocated for each array by the execution of an ALLOCATE statement (6.3.1). The standard does not appear to prohibit allocatable arrays of automatic objects. Question 1: Is it the intent to allow allocatable arrays of automatic character? FUNCTION FRED (J) CHARACTER(LEN=J), DIMENSION(:), ALLOCATABLE :: CH ALLOCATE (CH(100)) Question 2: If allocatable arrays of automatic objects are allowed, is it correct to assume the array must not have the SAVE attribute? Question 3: Character length is part of a character entity's type and type parameters. Was it intended that character entities whose length is specified by a variable expression or an * (assumed length character) be allowed to also have the POINTER or TARGET attribute? The third constraint of Section 7.5.2 states The target must be of the same type, type parameters, and rank as the pointer. In general, there should be no problem with allowing the POINTER and TARGET attribute for automatic arrays. However, there is a problem if TARGET is intended to be allowed for automatic character, both scalar and arrays, where the length is specified by a variable expression. Character length is part of the type and type parameters, but where length is specified by a variable, the above constraint cannot be diagnosed at compile time. Was it the intent to allow the TARGET attribute on any automatic objects, only on automatic arrays except where character length is specified by a variable expression, or for no automatic objects? If the intent is to allow TARGET on all automatic objects, the above constraint must be relaxed as it cannot be detected at compile time. ANSWER: (1) Yes, allocatable arrays of automatic character are allowed. (2) Yes, such an array must not have the SAVE attribute. (3) The TARGET attribute is allowed on any automatic object. The third constraint of section 7.5.2 cannot be diagnosed at compile time for automatic character targets or targets that are character dummy arguments with assumed length and, therefore, is relaxed by one of the supplied edits. Character entities whose length is specified by a variable expression or an * (assumed length character) are allowed to have the POINTER attribute. EDITS: 1. In the third constraint of section 7.5.2 [92:12] change ", type parameters," to ", kind type parameters," 2. Add at the beginning of the paragraph following the constraints of section 7.5.2 [92:15], "The target must have the same type parameters as the pointer." SUBMITTED BY: Jon Steidel HISTORY: 92-206 Initially drafted, with two possible responses 92-206b m123 "Second Possibility" rejected (9-9) 92-206b m123 "First Possibility" rejected (14-5) m124 "Second Possibility" adopted (14-2) 93-111 m125 ballot approved with Rolison edit 93-123 m125 Question 3 is not completely answered 93-150 edits m127 J. Shepherd, during Monday report, changed to status C noting that question 3 is not completely answered 93-318 m127 response withdrawn 94-043r1 m128 proposed response, approved uc 94-116 m129 X3J3 ballot approved 22-1 -------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.5.2.9, Restrictions on entities associated with dummy arguments, clearly states that if there is partial or complete overlap between actual arguments associated with two different dummy arguments of the same procedure, the overlapping portions may not be defined, redefined, or undefined during the procedure execution. It continues: This restriction applies equally to pointer targets. For example, in REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) B (3:5) cannot be defined because it is part of the actual argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument. Unfortunately, this example does not contain an explicit interface for the called subroutine, nor are there sufficient words to clearly state what is meant by the words and example provided. Question 1: Do the above restrictions hold when both dummy arguments are non-pointers? In this case the following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y END SUBROUTINE END INTERFACE Question 2: Same as question 1, only add the TARGET attribute to one or both of the dummy arguments. The following interfaces may describe SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), TARGET :: X, Y END SUBROUTINE END INTERFACE or INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y TARGET X END SUBROUTINE END INTERFACE Question 3: Do the above restrictions hold *upon entry* when both dummy arguments are pointers? That is, *upon entry* to SUB, is it safe to assume that pointer dummy arguments do not have overlapping elements which may get defined during execution of SUB? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), POINTER :: X, Y END SUBROUTINE END INTERFACE Question 4: Same as question 3, but one dummy argument is a pointer, one has the target attribute. *Upon entry* to SUB, is it safe to assume a pointer dummy argument does not point to any elements of a target dummy argument which may get defined during execution of SUB, but during the execution of SUB such an association may come to exist? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y POINTER X TARGET Y END SUBROUTINE END INTERFACE Question 5: Two derived type dummy arguments each have a subobject (or a subobject of a subobject etc.) which are pointers with the same type, kind type parameter, and rank. *Upon entry* to the subroutine, is it safe to assume such pointer subobjects do not have overlapping targets which may get defined? That is, in the following fragment, *upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 cannot have overlapping target elements which get defined during execution of SUB? SUBROUTINE SUB (X, Y) TYPE A SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_1 END TYPE TYPE B SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_2 END TYPE TYPE (A) :: X TYPE (B) :: Y ANSWER: There is a deficiency in the standard. The restrictions that hold for "normal" arguments are not necessarily appropriate when the arguments have the POINTER or TARGET attributes. Thus the answers to the specific questions are: Question 1: Yes Question 2: Yes if only one argument has the TARGET attribute, no if both have the TARGET attribute Question 3: No Question 4: No Question 5: No Discussion: Section 12.5.2.9 states While an entity is associated with a dummy argument, no action may be taken which affects the value or availability of the entity or any part of it, except through the dummy argument. This restriction was included to allow an implementation to employ "copy-in/copy-out" to handle the argument passing of normal arrays. However, this implementation model is not appropriate for arguments which have the POINTER or TARGET attributes (see interpretation 000125). If either argument could be implemented by copy-in/copy-out the existence of an overlap would make the result of the procedure indeterminate should some values in the overlap region be changed via either dummy argument. If both arguments have the POINTER or TARGET attributes, the arguments must essentially be passed by reference and the result of redefining values via either argument is fully determined. Where copy-in/copy-out is possible for either argument, the overlap of the actual arguments may not be preserved in the associated dummy arguments and hence changes made may not be consistently reflected back into the associated actual arguments. Where "call by reference" is required for both arguments, any overlap in the actual arguments is preserved in the associated dummy arguments and any changes in the dummy arguments are properly reflected in the associated actual arguments. EDITS: 1. In section 12.5.2.9, [180:4] after "dummy argument" add ", unless the dummy argument has either the POINTER or TARGET attribute" 2. In section 12.5.2.9, [180:36-38] in the second to last paragraph on the page, after "execution of the procedure" add ", unless all dummy arguments involved in the overlap have the POINTER or TARGET attribute". SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 -------------------------------------------------------------------------------- NUMBER: 000082 TITLE: Host association and generic names KEYWORDS: host association, generic name DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the program fragment 1 INTERFACE F 2 FUNCTION X(Y) ... 3 CONTAINS ... 4 INTEGER F(10) 5 I = F(2) Reading in 12.1.2.2.1, Host association: Statement 4 is a containing F. Thus F is the name of a local entity and any entity of the host that has F as its nongeneric name is inaccessible (text following list on page 164). Therefore the generic name, F, in the host is accessible. With that, is F(2) in statement 5 a reference to the generic name or to the array name? ANSWER: F(2) is a reference to the array name. Discussion: The rules in 12.1.2.2.1 concern the accessibility of nongeneric names of the host. A generic identifier in the host is only available in the contained scoping unit if that identifier is established to be generic (14.1.2.4). In this particular case, F is declared as an array and is therefore not established as a procedure in the contained scoping unit. EDITS: None. SUBMITTED BY: Richard Weaver HISTORY: 92-235 Submitted 92-209 Related question submitted 93-104 m124 Response proposed and approved by unanimous consent. 93-111 m125 ballot, return to subgroup based on Maine, Rolison Weaver comments; coordinate better with section 14 93-185 m125 Original presentation of more extensive edit 93-221 m126 Incorporation of edit and slightly expanded discussion. Passed by unanimous consent. Note: 32 (see text in), 86 and 90 are dependent on approval of 82. 93-255r1 m127 ballot failed 19-5 93-257 m127 006/82 Host association and generic names (Reid) 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-1 94-160 m129 WG5 ballot approved with Rolison edit 94-184 m129 Rolison edit as requested by WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Is the following code fragment standard conforming? INTERFACE SIN REAL FUNCTION MY_SIN(X) REAL, INTENT(IN) :: X END FUNCTION END INTERFACE Section 14.1.2.3 contains the following sentence: "When an intrinsic procedure, operator, or assignment is extended, the rules apply as if the intrinsic consisted of a collection of specific procedures, one for each allowed combination of type, kind type parameter, and rank for each argument or operand." This sentence indicates that there is a "hidden" generic interface for the intrinsic SIN that looks something like : INTERFACE SIN REAL FUNCTION DEFAULT_REAL_SIN(X) REAL, INTENT(IN) :: X END FUNCTION REAL FUNCTION REAL_DIFFERENT_KIND_SIN(X) REAL(KIND=), INTENT(IN) :: X END FUNCTION ... COMPLEX FUNCTION CSIN(X) COMPLEX, INTENT(IN) :: X END FUNCTION ... END INTERFACE Section 11.3.2 indicates that if a user supplies a generic interface SIN such as in the first example, the user interface will be treated as a single interface with the "hidden" generic intrinsic interface. However, according to the rules of section 14.1.2.3 the MY_SIN specific interface and the "hidden" DEFAULT_REAL_SIN specific interface are ambiguous. Therefore users must not write generic interfaces unless they are sure that the generic name they select and the arguments to the specific interfaces they specify will not conflict with any "hidden" generic interfaces implied by the generic intrinsics. ANSWER: The code fragment ought to be standard conforming, when the scoping unit that contains the interface does not specify the INTRINSIC attribute for the name SIN and does not access the intrinsic procedure SIN with that name by use association. An edit is provided to reflect this. Discussion: The difficulty of selecting a generic name that avoids any ambiguity with a generic intrinsic wasn't fully appreciated. There is a history of each new Fortran standard changing the specification of intrinsics. This may lead to potential conflicts where none existed previously. As the standard is currently written, if a generic interface were written an ambiguity as described in the rules of 14.1.2.3, could not be avoided without knowledge of all intrinsics. Requiring such knowledge is a severe hindrance to the useability of generic interfaces. An edit is supplied so that the scoping unit that contains the generic interface must indicate if the generic interface is to extend a generic intrinsic procedure. In this way the users can control whether their generic interfaces will or will not extend any generic intrinsic. Section 14.1.2.3 indicates how its rules apply to intrinsic procedures that are being extended. This edit describes when an generic intrinsic procedure is being extended. The rules for resolving procedure references to names established to be generic are given in section 14.1.2.4.1. Section 12.3.2.3 describes the semantics of the INTRINSIC statement. An edit is supplied for this section to clarify that the name of a generic intrinsic function with the INTRINSIC attribute can also be the name of a generic interface. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 13, 14.1.2.3 EDITS: 1. In section 14.1.2.3 add after the second sentence [242:28]: "If a generic interface has the same name as an accessible generic intrinsic procedure and the scoping unit either contains an INTRINSIC attribute specification for that name or accesses that generic intrinsic procedure with that name by use association, the generic interface extends the generic intrinsic procedure." 2. In section 12.3.2.3 add to the end of the first paragraph after the constraint [171:15]: "A generic intrinsic procedure with a name that has the INTRINSIC attribute can also be the name of a generic interface." SUBMITTED BY: Larry Rolison HISTORY: 92-210 m123 submitted 93-180 m125 Response, approved 19-1 93-255r1 m127 ballot failed 21-3 94-163r1 m129 Clarified answer and added another edit. withdrawn as new edit needs rewording. -------------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and host association KEYWORDS: use association, host association, generic interface, EXTERNAL statement DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups in a module. Host association, 12.1.2.2.1 states An internal subprogram, a module subprogram, or a derived-type definition has access to the named entities from its host via host association. The accessed entities are known by the same name and have the same attributes as in the host and are variables, constants, procedures including interfaces, derived types, type parameters, derived-type components, and namelist groups. Question 1: Do use and host association access the same entities? What entities does each access? Question 2: For both use and host association, what entities are not accessed? Question 3: For host and use association, if the host or module referenced contains an EXTERNAL statement for ABC, is ABC an accessed entity that has the EXTERNAL attribute? Note that an EXTERNAL statement is not a "named entity" (the statement has no name) and the procedure named in the statement is not in the host or module (that is the reason for the EXTERNAL statement). The answer to question 1 or 2 should also answer this question. Question 4: Given the following PROGRAM A MODULE M USE X USE Y CONTAINS SUBROUTINE B USE M is subprogram B associated in some way with X? What way? Note that A, the host of B, "accesses" entities in X by use association; the entities in X are not "in" B's host. Question 5: In the same example is subprogram B associated in some way with Y? What way? As with question 4 note that the entities in Y are "accessed" from M; the entities in Y are not in M and use association refers to the entities "in the module". Question 6: Given the following: MODULE A ! level 1 host USE AA INTERFACE F ... CONTAINS SUBROUTINE B ! module subroutine, level 2 host USE BB INTERFACE F .... CONTAINS SUBROUTINE C ! internal subprogram USE CC INTERFACE F ... .... = F(X) ! an invocation of the generic name F and where modules AA, BB, and CC all contain a generic interface for F: How is the invocation of the generic name F resolved? (in what sequence are which hosts and uses considered?) Note the levels of nesting: A contains B contains C. Section 14.1.2.4.1, "Resolving procedure references to names established to be generic", (3), seems to consider only B, the host of C, and not A. ANSWER: Answer 1: Entities declared PRIVATE are potentially accessible by host association but not by use association. Otherwise, it was intended that the classes of entities made accessible by these two forms of association be the same. These are named data objects (including both constants and variables), derived types, derived type components, procedures (both those defined in the host or module and those declared there and defined elsewhere; both those identified by names and those identified by other generic identifiers), and namelist groups. See sections 12.1.2.1 and 11.3.2. An edit, in interpretation 000082, is provided to make the cited text consistent. Answer 2: Entities not in the list in 12.1.2.1 and 11.3.2 are not made accessible. For example, FORMAT statement labels, construct names, and common block names are not made accessible. Answer 3: In such an example, ABC would be accessible. Section 12.3.2.2 indicates that the EXTERNAL statement specifies a list of names that are procedures. In the host or module, ABC is the name of a procedure and thus is potentially an accessible entity; it is not necessary that the definition of ABC be present in the host or module. Answer 4: The entities of module X made accessible in A by use association are made accessible in B by host association. Note that each such entity has a local name (or other identifier) in A. See Section 11.3.2. Answer 5: The entities of module Y made accessible in M by use association are made accessible in B by use association. Note that each such entity has a local name (or other identifier) in M. See Section 11.3.2. Answer 6: In effect, first C and CC are checked for a consistent specific interface, then B and BB, then A and AA, and finally (if F were the generic name of an intrinsic function) the intrinsics are checked. In applying 14.1.2.4.1 to a reference in C, item (1) provides the check of interfaces in C (including those made accessible from CC), and item (3) provides for a recursive application of 14.1.2.4.1 to B. In this recursive application, (1) checks B (and BB), and (3) results in a further recursive application of 14.1.2.4.1 to A. In this application, (1) checks A (and AA), (3) is not applicable, and (4) checks the intrinsics. 14.1.2.3 establishes that there must be no ambiguity in distinguishing the interfaces declared in C from those made accessible from CC. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 92-214 Submitted 92-281 m123 Response proposed (11-7 was insufficient for approval) 93-030r1 Revised response proposed m124 Approved (15-1) 93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits 93-234 m126 edit replaced by that in item 82, approved uc Note: cannot go forward until 000082 does. 94-034 m128 Relying on edit in 000082 that has been removed, status changed to X3J3 consideration in progress -------------------------------------------------------------------------------- NUMBER: 000087 TITLE: PARAMETER statements and SAVE statements KEYWORDS: PARAMETER statement, named constant, SAVE statement DEFECT TYPE: Erratum STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: Can a named constant appear in a SAVE statement? In FORTRAN 77 named constants were not allowed to appear in a SAVE statement. Fortran 90 appears to allow named constants in SAVE statements. ANSWER: No, a named constant must not appear in a SAVE statement. Edits are provided to indicate this restriction. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 5.1.2.5, 5.2.4 EDITS: 1. Change the sixteenth constraint of section 5.1 to [40:24] The SAVE attribute must not be specified for an object that is in a common block, a dummy argument, a procedure, a function result, an automatic data object, or an object with the PARAMETER attribute. 2. In section 5.1, change the first sentence of the next to last paragraph before the examples [41:9]: The presence of = implies that is a saved object, except for an in a named common block or an with the PARAMETER attribute. 3. Remove the penultimate sentence of 5.1.2.5, "The SAVE attribute ... result, or an automatic data object." [47:39] 4. Change the first constraint of section 5.2.4 to [50:9] An must not be the name of an object in a common block, a dummy argument name, a procedure name, a function result name, an automatic data object name, or the name of an object with the PARAMETER attribute. SUBMITTED BY: Janice C. Shepherd 93-011 HISTORY: 93-011 Submitted with proposed response m124 After minor edits, adopted by unanimous consent 93-111 m125 ballot, returned to subgroup based on Maine comment 93-136r m125 revised response, adopted 18-2. 93-255r1 m127 ballot failed 21-3 93-303r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 27-0 (!) 94-094r1 m128 revised wording of edit 2, but not intent. Approved uc Moved to "ready for WG5" without objection 94-160 m129 WG5 ballot approved with edit recommended 94-175 m129 suggested edit from WG5 ballot declined -------------------------------------------------------------------------------- NUMBER: 000088 TITLE: Common block names and local names KEYWORDS: common block name, local name DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 12.1.2.2.1 states A name that appears in the scoping unit as (5) an object name in an entity-decl ... ... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Is this consistent with 14.1.2.1 "Common Blocks" ? ANSWER: Yes. Discussion: Section 12.1.2.2.1 states rules about host association. Host association does not apply to common block names but does apply to variables within a common block. If a common block is defined in the host scope then a variable of that common block can be accessed by host association, if no local entity makes the variable inaccessible by that name by host association. The storage units of that host common block can be accessed by means other than host association. If the scope contains its own definition of the common block then the storage units of the common block are accessible in the scope. Consider this program fragment: SUBROUTINE HOST COMMON /CC/ A,B,C ... CONTAINS SUBROUTINE INNER() COMMON /CC/ D,E,F INTEGER A,C ... Variables A and C are local to the scope of subroutine INNER. The host variables A and C are not accessible by those names by host association. However variable D is storage associated with variable A, thus the storage for variable A is accessible within subroutine INNER, but not by the name A. An edit is provided to clarify that the list in section 12.1.2.2.1 is stating those conditions under which an entity in the host is inaccessible by host association by a particular name. EDIT: In section 12.1.2.2.1 in the sentence that contains the list of items replace 'that has this as its nongeneric name is inaccessible.' with 'that has this as its nongeneric name is inaccessible by that name by host association.' [164:21] SUBMITTED BY: Dick Weaver HISTORY: 92-219 Submitted 92-324 m123 Response proposed (vote of 14-6 was insufficient for approval) 94-058 m128 New Response, approved uc 94-116 m129 X3J3 ballot approved 22-1 -------------------------------------------------------------------------------- NUMBER: 000089 TITLE: Errors in the DATA statement description KEYWORDS: DATA statement, structure constructor DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Does the text description in section 5.2.9 [53:4-20] of the values permitted in a DATA statement contain a recurring flaw? This description continually refers to the constant values in the list as simply "constants". According to R533 a structure constructor is allowed in the list, but it is not a constant; rather it is a constant expression. This is demonstrated by: The definition of "constant" in 2.4.3.1.2. There are only two broad categories of constants defined: named constants and literal constants. The syntax rules for "constant" (R305-R307) reinforce this definition by defining only two nonterminals: and . The description of the structure constructor in section 4.4.4 [37:10-11] states: A structure constructor whose component values are all constant expressions is a derived-type constant expression. ANSWER: Yes, there is a flaw in Section 5.2.9 in the text description of the values permitted in a DATA statement. The following edits eliminate this flaw. Discussion: In considering the edits to Section 5.2.9 to repair this flaw, it became apparent that the second sentence in the third paragraph following the constraints, [53:4-5] "Each such value ... host association." applied equally to named constants and structure constructors. This means that the type definition for the structure constructor must be accessible. Furthermore, this should be stated as a constraint. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.9, 2.4.3.1.2, 3.2.3, 4.4.4 EDITS: 1. Add a new constraint after the second constraint following R537: [52:25] If a DATA statement constant value is a named constant or a structure constructor, the named constant or derived type must have been declared previously in the scoping unit or made accessible by use or host association. 2. Delete the second sentence in the third paragraph following the constraints [53:4-5], "Each such value ...host association." 3. In the third sentence [53:6], replace "following constant" with "following constant value". 4. In the next paragraph, second sentence [53:11], change "constant" to "constant value". 5. In the following paragraph, last sentence [53:17], change "constant" to "constant value". 6. In the sixth paragraph [53:18-19], change "value of the constant" to "constant value" (twice) SUBMITTED BY: Larry Rolison - X3J3/92-221 HISTORY: 92-221 m123 Submitted 93-032 m124 Draft response 93-032r1 m124 Revised based on comments from Rolison, adopted uc 93-111 m125 ballot accepted with Maine edit (assumed done at m125) 93-150 m125 Edits from X3J3 ballot 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000090 TITLE: Subroutine and function names in nested scopes KEYWORDS: procedure names, scope - nested, scoping unit DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.1.2.2.1 states A name that appears in the scoping unit as (2) a function-name in a function-stmt ... (3) a subroutine-name in a subroutine-stmt... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Entities that are local (14.1.2) to a procedure are not accessible to its host. 1. If this is true, how can hosts reference internal procedures, module procedures and interface blocks (the text in 2.2.3.3 pertains only to internal procedures and is somewhat vague) ? 2. Are entities local to an interface body accessible to the host? (i.e., should the "Entities that are local ..." rule above be more general?) ANSWER: 1. The text cited from sections 12.1.2.2.1 and 14.1.2 contains errors. The text in 12.1.2.2.1 was intended to describe how a name established to be: a) a derived type name in the scope of an internal subprogram or in the scope of a module subprogram; b) an internal subprogram name in the scope of a module subprogram; c) a procedure name by its appearance in an interface body in the scope of an internal subprogram or in the scope of a module subprogram; makes inaccessible any entity of the host of the specified scope that has the name as its nongeneric name. Edits are provided to clarify this intent. Derived-type statements, SUBROUTINE statements and FUNCTION statements establish a new scope, but the derived-type name, subroutine name and function name defined by those statements are local entities of the host scope. Additional rules are then needed to prevent the name of a module procedure, internal procedure, procedure specified in an interface body, or derived type from conflicting with the names of local and global entities within the scope. These rules are included in the edits below. 2. No, entities local to an interface body are not accessible to the host. This is part of the more general rule stated in the first two paragraphs of section 14. "Entities are identified by lexical tokens within a scope..." "By means of association, an entity may be referred to... in a different scoping unit..." Thus, in the absence of association, an entity is not accessible in different scoping units. The statement in section 12.1.2.2.1 that "Entities that are local (14.1.2) to a procedure are not accessible to its host." is there to explain two things: a) Host association allows entities of a host to be accessed in a procedure but entities that are local to a procedure are not accessible to its host. b) Host association applies to derived-type definitions, and component names local to those derived-type definitions are accessible in the host scope. (14.1.2.5) EDITS: 1. In section 12.1.2.2.1: [163:39] change: A name that appears in the scoping unit as an in an to: A name that is declared to be an external procedure name (by an or an ), or that appears as a in a 2. In section 12.1.2.2.1: [164:4] change: (2) A in a to: .......................................... within an 3. In section 12.1.2.2.1: [164:6] change: (3) A in a to: .............................................. within an 4. In section 12.1.2.2.1: [164:7] delete item (4) of the list and renumber the rest of the list. SUBMITTED BY: Dick Weaver, X3J3/92-220 HISTORY: 92-220 submitted 92-328 m123 first draft response in (failed) 93-107 Alternate proposal submitted m124 Action deferred because of short lead time. m125 edits per Kelble notes! m125 minutes, page 13, approved uc 93-234 m126 most edits replaced by item 82, approved uc 93-255r1 m127 ballot passed 24-0 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot failed 25-2 -------------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE attribute, module, conformance DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress *************************************************** * * * NOT CURRENT * * * * ----------- SEE 93-220 * * * *************************************************** QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint is violated or confirmed across module definitions? More specifically should the following two constraints: The third constraint following R522: [49:26-28] A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility and must not have a generic identifier that has PUBLIC accessibility. The fourth constraint following R424: [33:10-11] If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private. be diagnosed in the following program?: MODULE A TYPE X INTEGER :: I END TYPE X TYPE Y TYPE (X) :: R ! Note component of type X END TYPE Y CONTAINS FUNCTION F() ! Module function of type X TYPE(X) :: F END FUNCTION F END MODULE A MODULE B USE A PRIVATE :: X ! Note component of type Y now has ! a PRIVATE attribute ! Note also that module function F now ! has PRIVATE attribute END MODULE B ANSWER: There are no constraints that apply across module definitions. The specific constraints cited are not violated in the example program containing module A and module B. Note that the comments in module B in the example program are incorrect. Discussion: With regard to the example above, the accessibility attributes (PUBLIC and PRIVATE) apply to a type name, not the type itself. For example, the following is allowed: MODULE C USE A, X1 => X, X2 => X PRIVATE :: X1 PUBLIC :: X2 ... END MODULE C Conformance is based only on the accessibility of a type in the module in which the type is defined. Y and F are defined in module A where the type X is public. If a type with a component X were defined in module B, it would have to be a private type or contain the PRIVATE statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4, 4.4.1, and 5.2.3 EDITS: None. SUBMITTED BY: Maureen Hoffert HISTORY: 92-225 m123 Submitted 93-024 m124 Response adopted (14-3). 93-111 m125 ballot, return to subgroup based on Hirchert comment Consider restricting constraints to "within a scoping unit" 93-137r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response, containing the opposite answer, was prepared, passed, and then withdrawn (see 93-177) 93-177 an alternate response (see 93-137) 93-220 m126 withdrawn -------------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and storage association KEYWORDS: association - pointer, association - storage DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following example program: PROGRAM PROG INTEGER :: VAR COMMON /COM/ VAR VAR = 5 CALL SUB END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT PTR => TGT ... END SUBROUTINE SUB Is the pointer assignment legal? Although the entity named TGT was declared with the TARGET attribute, a storage associated entity, VAR, was not. ANSWER: The pointer assignment is legal only because PTR is declared within the scoping unit of SUB and is not accessible outside the scoping unit of SUB. Discussion: By the rules of 6.3.3.2, PTR becomes undefined upon return from SUB to the calling program. Note however that if PTR was also accessible in the scoping unit PROG and the variable VAR was not declared with the TARGET attribute, the program would not be standard conforming. The following example is not standard conforming. PROGRAM PROG INTEGER :: VAR INTEGER,POINTER :: PTR COMMON /COM/ VAR, PTR VAR = 5 CALL SUB ... END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT, PTR PTR => TGT ... END SUBROUTINE SUB After the call to SUB, PTR is pointer associated with the same storage that VAR is storage associated with. In this case, VAR must be declared with the TARGET attribute in the scoping unit PROG for the program to be standard conforming. EDITS: None. SUBMITTED BY: Len Moss HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning S20.121(27) m121 Separate request submitted following meeting 92-226 m123 Submitted 93-034r m124 Response, adopted by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000093 TITLE: Scalar pointer function results KEYWORDS: function result, POINTER attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: May a scalar function result have the POINTER attribute? ANSWER: Yes. Discussion: The text that appears as the last paragraph of 5.1.2.4.3 is intended to apply to all function results even though it appears in a section titled, "Deferred-shape array". To clarify this point, the edit below moves that text to section 5.1 which has the more general title, "Type declaration statements". EDIT: 1. Delete the last paragraph of 5.1.2.4.3 [46:43]. 2. Insert the following paragraph after the second paragraph following the constraints in 5.1 [40:38+] A function result may be declared to have the POINTER attribute. SUBMITTED BY: Len Moss - X3J3/92-227 HISTORY: 92-227 m123 Submitted 93-075 m124 Proposed response, adopted by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved with Rolison edit 94-185 m129 Rolison edits from WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: The edits below add a definition of "declaration" to the glossary and, for clarity, also add a definition of "specification". EDITS: 1. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): The specification of for various program , Often this involves specifying the of a or specifying the of a ." 2. In Annex A, add to page 260 after "size" [260:14+] Specification: The assignment of attributes and properties to names. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 -------------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification expression KEYWORDS: expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTIONS: In section 7.1.6.2 "Specification expression": 1. In item (9) should not the restriction "defined by an ALLOCATE statement" be "allocatable" instead? That is, the ALLOCATE statement does not have to exist, it is being allocatable -- even if never allocated -- that is restricted. [79:14-15] And the same comment for pointer assignment. [79:14-15] 2. Would Item (9) be clarified if "local" were inserted before "variable"? [79:14] 3. In the text beginning "and where any subscript ..." should not "is" be "must be"? As written it states that any subscript is a restricted expression. [79:17] 4. In the text beginning "A specification expression (R509, R514, R515)... should not the "(R509, R514, R515)" be deleted? ANSWER: 1. Yes, see edits below. Edits are provided for similar problems in other sections. 2. No. 3. No, this is part of a long and complex sentence which begins on the previous page. 'Is' is the correct form and parallels the rest of the sentence and describes what a restricted expression 'is', not what a subscript is. 4. There is redundancy, but not an error. EDITS: 1. Replace 7.1.6.1 (6), in the first list, with the following: [77:24-28] (6) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) a constant expression, or b) a variable whose properties inquired about are not: 1) assumed 2) defined by an expression that is not a constant expression or 3) definable by an ALLOCATE or POINTER assignment statement 2. Replace 7.1.6.1 (6), in the second list with the following: [78:6-10] (6) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) an initialization expression, or b) a variable whose properties inquired about are not: 1) assumed 2) defined by an expression that is not a initialization expression or 3) definable by an ALLOCATE or POINTER assignment statement 3. Replace 7.1.6.2 (9) with the following: [79:11-15] (9) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) a restricted expression, or b) a variable whose properties inquired about are not: 1) dependent on the upper bound of the last dimension of an assumed-size array 2) defined by an expression that is not a restricted expression or 3) definable by an ALLOCATE or POINTER assignment statement SUBMITTED BY: Dick Weaver HISTORY: 92-233r m123 Submitted 93-086 m124 Revised edit, passed 15-2 93-111 m125 ballot, return to subgroup, based on Maine, Rolison, Weaver comments -- possible error and coordinate with 000047 93-143 m125 revised, withdrawn 93-211 m126 revised, approved uc 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000098 TITLE: subsumed by 000131 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDIT: SUBMITTED BY: Joanne Brixius X3J3/92-234 HISTORY: 92-234 Submitted 92-273r2 m123 Approved 93-071 m124 approved uc N881 WG5 ballot failed 93-165 m125 Revised following letter ballot, approved uc 93-255r1 m127 ballot failed 21-3 subsumed by 000131 -------------------------------------------------------------------------------- NUMBER: 000099 TITLE: Generic interfaces KEYWORDS: generic interface DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: 11.3.2, page 158, paragraph beginning "If two or more" states that: If two or more generic interfaces that are accessible in a scoping unit have the same name, ..., they are interpreted as a single generic interface. 14.1.2.4.1, page 244, states (1) If the reference ... of an interface block that has that name and either is contained in the scoping unit ... or is made accessible by a USE statement... (3) ... if the name is established to be generic in that host scoping unit ... Question 1: What section 11 seems to imply will be treated as a single interface is, in Section 14, actually treated as individual interfaces. Which is correct? Question 2: If the text from 11.3.2 above applies to more than just use association, should it be moved to 12.3.2.1 "Procedure Interface Block"? ANSWER: Answer 1: Although they use different descriptive models, both are correct. Answer 2: Although there might be a more appropriate location for this text, 12.3.2.1 does not appear to be such a location. Discussion: Applied to standard-conforming programs, the rules of 14.1.2.4 (which separately consider the interfaces accessible in host and contained scoping unit) resolve to the same procedure as first applying the host association rules in 12.1.2.2.1 and then applying 11.3.2 where appropriate. It is true that the cited text in 11.3.2 applies to both use association and host association and thus it is not entirely appropriate that it is in a section that otherwise applies only to use association. On the other hand, it applies to all generic names, not just those specified in a procedure interface block, so it would be similarly inappropriate for it to be in 12.3.2.1. See, also, interpretation 000082. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 92-236 m123 Submitted 93-232 m126 Draft response based on edits in item 82. approved uc 93-255r1 m127 ballot passed 24-0 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved with suggested edit 94-168 m129 suggested edit from WG5 ballot declined --------------------------------------------------------------------------------