PC file: 94-006a1.0 Archive: 94-006r1.A0 -------------------------------------------------------------------------------- NUMBER: 00000b TITLE: Minor edits and corrections to ISO/IEC 1539:1991 (E) KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: ANSWER: 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] LAST SIGNIFICANT CHANGE: 93-..-.. 00000b ballot approved HISTORY: Submitted at X3J3 m124, 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) -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections to ISO/IEC 1539:1991 (E) KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response 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: 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: 5. Page 245, section 14.1.2.5, in the second sentence [245:4] 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 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: LAST SIGNIFICANT CHANGE: 93-12-20 00000c ballot: 4 approved, 5 failed 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-9 94-028r1 m128 approval of items 6-7 uc 94-084 m128 correction of item 5, approved uc -------------------------------------------------------------------------------- NUMBER: 000001 TITLE: Optimization of Fortran programs KEYWORDS: expression - arithmetic, mathematical equivalence, numeric operations, optimization DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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) LAST SIGNIFICANT CHANGE: 93-11-12 000001 ballot failed 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 -------------------------------------------------------------------------------- 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 approved; ready for WG5 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: -- edit descriptors are not in the category "keywords" and need not be delimited by blanks. -- blanks are allowed in edit descriptors. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.3.1, 10.1.1 EDITS: 1. Section 2.5.2 following the sentence "Keywords appear ... through 12." [16:5] add the following: "Note that in addition to keywords, upper-case letters may also appear in various other lexical tokens. Examples include operators such as .EQ., edit descriptors such as BN or Iw[.m], and literal constants such as B'digit[digit]...'." Note that the first edit depends on a change made in item 58 which moves a line from section 3.2.1 to 2.5.2 2. Section 3.2 last sentence [19:35-36] insert ", edit descriptors" following "... , labels". 3. 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 X3J3/92-044 S20.120, number 4 X3J3/92-075 X3J3/92-145 Draft Interpretation by CIO, withdrawn Approved as X3J3/92-176 at m122 by uc X3J3/92-326 ballot comments (jw note) minutes m124 approved 15-2 X3J3/93-111 m125 ballot approved; accept Martin edits -------------------------------------------------------------------------------- NUMBER: 000007 TITLE: Duplicate module procedures in interface blocks KEYWORDS: module procedure name, interface block, generic name DEFECT TYPE: Interpretation 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: Yes. Discussion: There is no restriction in the standard that would prohibit a module procedure name from being referenced on more than one MODULE PROCEDURE statement for a given generic name. There is a restriction that prohibits an explicit interface for a procedure from appearing more than once in a scoping unit (section 12.3.2.1). This restriction does not apply to module procedure names being referenced in MODULE PROCEDURE statements as MODULE PROCEDURE statements do not specify the explicit interfaces of the module procedures. Example: INTERFACE INT_1 MODULE PROCEDURE FOO, FOO MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 END INTERFACE INT_1 INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INT_2 INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C END INTERFACE INT_2 In this code fragment FOO and FOO1 are both referenced more than once within an interface block for the generic name INT_1 and FOO2B is referenced more than once within an interface block for the generic name INT_2. While referencing a module procedure name more than once within one or more interface blocks for a given generic name does not appear to be very useful, it need not be prohibited. REFERENCES: EDIT: None SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) LAST SIGNIFICANT CHANGE: 93-12-20 000007 ballot failed HISTORY: 120-MBSH-4A (120.096A) Original interpretation X3J3/92-039 Adopted because this interpretation is more consistent with requirements concerning duplication of other specification statements in a given scoping unit. X3J3/92-095 modification WG5/N786A Commented on, Victoria meeting, item marked 1167/36+. X3J3/92-155A m122 approved uc 94-034 m128 X3J3 ballot failed 25-3 94-093 m128 alternate answer proposed, approved uc -------------------------------------------------------------------------------- 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: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.3.2.1, & 14.1.2 EDITS: None. SUBMITTED BY: Larry Rolison, 120-LRR-4 (120.029), question 3 LAST SIGNIFICANT CHANGE: ..-..-.. 000011 before m123 HISTORY: Originally passed as 120-MBSH-1A (120.084A) Revised in response to ballot comments at m123, but no vote taken - withheld for further consideration 93-029 Slight rewording for clarification Approved by unanimous consent at m124. 93-111 m125 X3J3 ballot approved with Rolison edits -------------------------------------------------------------------------------- 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 draft response 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 that 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. REFERENCES: ISO/IEC 1539:1991 sections 5.2, 5.2.10, 5.3, 5.4, 7.1.6.2 and C.5.1 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 Corregendum 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 in question." 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 LAST SIGNIFICANT CHANGE: 93-07-16 000012 edit added, approved HISTORY: 120-LJM-5 (120-093) X3J3/92-172 m122 modified, passed 12 subsumes 23 following letter ballot X3J3/93-73r2 m124 adopted uc X3J3/93-111 m125 ballot approved with Rolison edits X3J3/93-150 m125 edits X3J3/93-227r1 m126 revised to make 12, 114 and 134 consistent, edit added, approved uc X3J3/93-255r1 m127 ballot failed 19-5 m127 12 subsumes 114, 134 X3J3/93-328 m127 response X3J3/94-050 m128 revised edits, approved uc -------------------------------------------------------------------------------- NUMBER: 000023 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: REFERENCES: 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) LAST SIGNIFICANT CHANGE: 93-11-12 000027 ballot failed HISTORY: 120-LJM-3A (120.081A) Original response proposed at m121 X3J3/92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 X3J3/92-093A m121 Approved X3J3/92-329 (jw note) Approval rescinded at m123 (uc) X3J3/93-099r1 m124 Revised response adopted (15-2) X3J3/93-111 m125 ballot failed, returned to subgroup X3J3/93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. X3J3/93-255r1 m127 ballot failed 17-7 -------------------------------------------------------------------------------- NUMBER: 000028 TITLE: Precedence of use or host association KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: 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 Question 1: 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? 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 Question 2: Is the reference to A in statement 20 a reference to the host associated array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER: In both cases, it is a reference to the host associated entity. 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, 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)) LAST SIGNIFICANT CHANGE: 94-02-11 000028 response approved HISTORY: 120-RL-3 (120.060) ui 105, ballot comments (jw note) 93-134 m125 unanimous consent X3J3/93-255r1 m127 ballot failed 23-1 X3J3/93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, 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 defined-operator 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) X3J3/92-106 Interpretation based on 121-JKR-2 X3J3/92-148A m122 Approved by unanimous consent X3J3/92-252 m124 Approved by unanimous consent X3J3/93-111 m125 ballot approved with Weaver edit -------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 array constructor 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 ac- value 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 array constructor. Since the length cannot always be determined at compile time, the constraint must be changed to prose. REFERENCES: ISO/IEC 1539:1991 (E) section 4.5 EDITS: 1. Delete the second constraint following R435. [38:3] 2. Add the following paragraph after the constraints in 4.5. [38:4] Each ac-value {in italics} expression in the array-constructor {in italics} 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 LAST SIGNIFICANT CHANGE: 93-02-12 000030 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - X3J3/93-070 m124 Question 3. submitted as X3J3/93-100 m124 proposed response, adopted by unanimous consent X3J3/93-111 m125 ballot approved with Rolison edit -------------------------------------------------------------------------------- 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 is standard conforming. 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 -------------------------------------------------------------------------------- NUMBER: 000034 TITLE: subsumed by 000033 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: REFERENCES: 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: REFERENCES: 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: X3J3 approved; ready for WG5 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) LAST SIGNIFICANT CHANGE: 93-02-12 000039 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 -------------------------------------------------------------------------------- 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. REFERENCES: ISO/IEC 1539:1991 sections 6.3.3.2, 12.3.1.1, and C.5.3 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 LAST SIGNIFICANT CHANGE: 93-02-12 000041 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) X3J3/92-070 m121 Approved Approval rescinded at m123 (uc) X3J3/93-101 m124 Revised response adopted by uc X3J3/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 LAST SIGNIFICANT CHANGE: 93-02-12 000049 item split HISTORY: X3J3/92-109A m121 Approved 19-0 X3J3/92-313 m123 response to ballot comments and approved by uc X3J3/93-105 Revised in response to ballot comments X3J3/93-152 m125 New edit, rejected X3J3/94- m128 New edit, -------------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving generic procedure references KEYWORDS: generic name, interface block, intrinsic procedure DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991(E) Sections 14.1.2.4 and 14.1.2.4.1 EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: X3J3/92-048 pg 29-30, 34-40, 51, 52, One of the questions raised in X3J3/92-052 pg 1-3 One of the questions raised in X3J3/92-119 Initially drafted X3J3/92-157 m122 approved -------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.5.2, 3.2.1, 12.4.1,& 13.10 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. X3J3/92-164A m122 approved 17-4 ballot comments, 92-326 (jw note) minutes m124 approved 15-2 X3J3/93-111 m125 ballot approved with Kelble edits -------------------------------------------------------------------------------- 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) LAST SIGNIFICANT CHANGE: 93-02-12 000070 revised HISTORY: X3J3/92-264 Question (a) originally posed X3J3/92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) X3J3/92-283 Response proposed Approved by unanimous consent at m123. X3J3/93-018 Response questioned by John Reid in X3J3/93-103 Revised response proposed Approved by unanimous consent at m124. X3J3/93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? X3J3/94- 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: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.5.2.1, 5.5.2.3, 5.5.2.5, and 11.3.2 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 LAST SIGNIFICANT CHANGE: 92-11-13 000071 added edits to previously proposed interpretation 000071 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 -------------------------------------------------------------------------------- NUMBER: 000073 TITLE: Description of the MERGE intrinsic function KEYWORDS: function - elemental, MERGE, array construction function DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 13.8.6, 13.10.16, 13.13.67 EDIT: None SUBMITTED BY: Dick Weaver X3J3/92-197 LAST SIGNIFICANT CHANGE: 93-02-12 000073 HISTORY: X3J3/92-197 Submitted X3J3/92-322 m123 Draft response (not approved) X3J3/93-090 Response in passed 14-4 X3J3/93-111 m125 ballot approved with Rolison edit -------------------------------------------------------------------------------- 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 interface-block 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 constraint is redundant with the second constraint in section 11.4. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.4, 12.3.2.1 EDITS: None. SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-13 000075 first draft response HISTORY: X3J3/92-200 X3J3/92-323 m123 Draft response, not approved X3J3/92-323 m124 reconsidered; reapproved uc X3J3/93-111 m125 ballot approved -------------------------------------------------------------------------------- NUMBER: 000076 TITLE: Attributes, properties, characteristics KEYWORDS: data object, attribute, property, characteristics DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) Introduction, Sections 1, 2, 4, 5, 12, 13, and Annex A EDITS: None SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-05-14 000076 response, adopted HISTORY: X3J3/92-202r m123 Submitted along with suggested edits X3J3/92-248 A related question appears in X3J3/92-305 suggested edits X3J3/92-307 suggested edits X3J3/93-112r m125 Draft response, adopted 15-6 X3J3/93-255r1 m127 ballot passed 23-1 -------------------------------------------------------------------------------- NUMBER: 000077 TITLE: Miscellaneous questions KEYWORDS: entity, data entity, data object, variable, external subprogram DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) Sections 2, 4, 6, 7, 8, 9, 13, and Annex A 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 LAST SIGNIFICANT CHANGE: 93-05-14 000077 response, adopted HISTORY: X3J3/92-203 m123 Submitted along with suggested edits X3J3/93-113 m125 Draft response, adopted 18-1 X3J3/93-255r1 m127 ballot passed 23-1 -------------------------------------------------------------------------------- NUMBER: 000079 TITLE: Automatic character and ALLOCATABLE, POINTER and TARGET attributes KEYWORDS: allocatable, automatic, character, pointer, target, array allocatable, array automatic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 5.1 states: The specification-expr (7.1.6.2) of a type-param-value (5.1.1.5) or an array-spec (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 = initialization-expr. 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. REFERENCES: ISO/IEC 1539:1991 sections 5.1, 5.1.2.9, and 7.5.2. EDITS: 1. In the third constraint of section 7.5.2 change [92:12] ", type parameters,". to ", kind type parameters," 2. Add at the beginning of the paragraph following the constraints of section 7.5.2, "The target must have the same type parameters as the pointer." [92:15] SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 93-02-10 000079 HISTORY: X3J3/92-206 Initially drafted, with two possible responses X3J3/92-206b m123 "Second Possibility" rejected (9-9) X3J3/92-206b m123 "First Possibility" rejected (14-5) "Second Possibility" adopted at m124 (14-2) X3J3/93-111 m125 ballot approved with Rolison edit X3J3/93-123 m125 Question 3 is not completely answered X3J3/93-150 edits m127 J. Shepherd, during Monday report, changed to status C noting that question 3 is not completely answered X3J3/93-318 m127 response withdrawn X3J3/94-043r1 m128 proposed response, approved uc -------------------------------------------------------------------------------- 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 existance 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. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.9 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". LAST SIGNIFICANT CHANGE: 93-11-12 000081 ballot failed SUBMITTED BY: Jon Steidel HISTORY: X3J3/92-208 m123 Submitted X3J3/93-85 m124 Proposed response, withdrawn X3J3/93-174 m125 Revised response, withdrawn X3J3/93-213 m126 Revised response, adopted by unanimous consent X3J3/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. 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. REFERENCES: EDITS: None. SUBMITTED BY: Richard Weaver LAST SIGNIFICANT CHANGE: 93-12-20 000082 ballot approved HISTORY: X3J3/92-235 Submitted X3J3/92-209 Related question submitted X3J3/93-104 m124 Response proposed and approved by unanimous consent. X3J3/93-111 m125 ballot, return to subgroup based on Maine, Rolison Weaver comments; coordinate better with section 14 X3J3/93-185 m125 Original presentation of more extensive edit X3J3/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. X3J3/93-255r1 m127 ballot failed 19-5 X3J3/93-257 m127 006/82 Host association and generic names (Reid) X3J3/93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-1 -------------------------------------------------------------------------------- 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 apppreciated. 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 13, 14.1.2.3 EDIT: 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." SUBMITTED BY: Larry Rolison LAST SIGNIFICANT CHANGE: 93-11-12 000083 ballot failed HISTORY: X3J3/92-210 m123 submitted X3J3/93-180 m125 Response, approved 19-1 X3J3/93-255r1 m127 ballot failed 21-3 -------------------------------------------------------------------------------- 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 11.3.2, 12.1.2.2.1, 14.1.2.3, and 14.1.2.4.1. EDIT: None. SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 93-07-16 000086 edit replaced by interpretation 82 HISTORY: X3J3/92-214 Submitted in X3J3/92-281 m123 Response proposed (11-7 was insufficient for approval) X3J3/93-030r1 Revised response proposed Approved at m124 by a vote of (15-1) X3J3/93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits X3J3/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: X3J3 approved; ready for WG5 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 LAST SIGNIFICANT CHANGE: 93-12-20 000087 ballot failed HISTORY: X3J3/93-011 Submitted with proposed response After minor edits, adopted by unanimous consent at m124 X3J3/93-111 m125 ballot, returned to subgroup based on Maine comment X3J3/93-136r m125 revised response, adopted 18-2. X3J3/93-255r1 m127 ballot failed 21-3 X3J3/93-303r1 m127 response appproved 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 -------------------------------------------------------------------------------- NUMBER: 000088 TITLE: Common block names and local names KEYWORDS: common block name, local name DEFECT TYPE: Erratum STATUS: X3J3 draft response 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. REFERENCES: 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 LAST SIGNIFICANT CHANGE: 92-11-13 000088 first draft response HISTORY: X3J3/92-219 Submitted X3J3/92-324 m123 Response proposed (vote of 14-6 was insufficient for approval) X3J3/94-058 m128 New Response, approved uc -------------------------------------------------------------------------------- NUMBER: 000089 TITLE: Errors in the DATA statement description KEYWORDS: DATA statement, structure constructor, named constant, constant DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 LAST SIGNIFICANT CHANGE: 93-02-10 000089 HISTORY: X3J3/92-221 m123 Submitted X3J3/93-032 m124 Draft response X3J3/93-032r1 m124 Revised based on comments from Rolison, adopted uc X3J3/93-111 m125 ballot accepted with Maine edit (assumed done at m125) X3J3/93-150 m125 Edits from X3J3 ballot -------------------------------------------------------------------------------- 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) REFERENCES: ISO/IEC 1539:1991 (E) sections 2.2.3.3, 12.1.2.2.1, and 14.1.2 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 LAST SIGNIFICANT CHANGE: 93-12-20 000090 ballot failed HISTORY: X3J3/92-220 submitted X3J3/92-328 m123 first draft response in (failed) X3J3/93-107 Alternate proposal submitted Action deferred at m124 because of short lead time. m125 edits per Kelble notes! m125 minutes, page 13, approved uc X3J3/93-234 m126 most edits replaced by item 82, approved uc X3J3/93-255r1 m127 ballot passed 24-0 X3J3/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 LAST SIGNIFICANT CHANGE: 93-05-14 000091 prior answer withdrawn HISTORY: X3J3/92-225 m123 Submitted X3J3/93-024 m124 Response adopted (14-3). X3J3/93-111 m125 ballot, return to subgroup based on Hirchert comment Consider restricting constraints to "within a scoping unit" X3J3/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) X3J3/93-177 an alternate response X3J3/93-220 m126 withdrawn -------------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and storage association KEYWORDS: association - pointer, association - storage DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) section 6.3.3.2. EDITS: None. SUBMITTED BY: Len Moss LAST SIGNIFICANT CHANGE: 93-02-10 000092 HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning S20.121(27) Separate request submitted following m121 X3J3/92-226 m123 Submitted X3J3/93-034r m124 Response, adopted by unanimous consent X3J3/93-111 m125 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.2 which has the more general title, "Type declaration statements". REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1 and 5.1.2.4.3 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 LAST SIGNIFICANT CHANGE: 93-02-10 000093 HISTORY: X3J3/92-227 m123 Submitted X3J3/93-075 m124 Proposed response, adopted by unanimous consent X3J3/93-111 m125 ballot approved -------------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: X3J3 draft response 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". REFERENCES: EDITS: 1. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): A declaration assigns attributes and properties to names. "Declaration" is a synonym for "Specification". 2. In Annex A, add to page 260 after "size" [260:14+] Specification: A specification assigns attributes and properties to names. SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 94-02-11 000096 draft response HISTORY: X3J3/92-232 Submitted X3J3/92-232r Draft response, withdrawn X3J3/93-144 m125 unanimous consent X3J3/93-255r1 m127 ballot failed 16-7 X3J3/94-103 m128 revised response, approved uc -------------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification expression KEYWORDS: expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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. REFERENCES: ISO/IEC 1539:1991 (E) sections 7.1.6.1, 7.1.6.2 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 LAST SIGNIFICANT CHANGE: 93-07-16 000097 m126 revised edits, approved HISTORY: X3J3/92-233r m123 Submitted X3J3/93-086 m124 Revised edit, passed 15-2 X3J3/93-111 m125 ballot, return to subgroup, based on Maine, Rolison, Weaver comments -- possible error and coordinate with 000047 X3J3/93-143 m125 revised, withdrawn X3J3/93-211 m126 revised, approved uc X3J3/93-255r1 m127 ballot passed 24-0 -------------------------------------------------------------------------------- NUMBER: 000098 TITLE: subsumed by 000131 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: REFERENCES: EDIT: SUBMITTED BY: Joanne Brixius X3J3/92-234 LAST SIGNIFICANT CHANGE: 93-11-12 000098 subsumed by 000131 HISTORY: X3J3/92-234 Submitted X3J3/92-273r2 m123 Approved X3J3/93-071 m124 approved uc N881 WG5 ballot failed X3J3/93-165 m125 Revised following letter ballot, approved uc X3J3/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. REFERENCES: EDIT: None. LAST SIGNIFICANT CHANGE: 93-12-20 000099 ballot approved SUBMITTED BY: Dick Weaver HISTORY: X3J3/92-236 m123 Submitted X3J3/93-232 m126 Draft response based on edits in item 82. approved uc X3J3/93-255r1 m127 ballot passed 24-0 X3J3/93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 --------------------------------------------------------------------------------