From janshep@watson.ibm.com Fri Jan 19 10:20:24 1996 Received: from convex.convex.com by mozart.convex.com (8.6.4/1.28) id KAA27234; Fri, 19 Jan 1996 10:20:14 -0600 Received: from watson.ibm.com by convex.convex.com (8.6.4.2/1.35) id KAA26950; Fri, 19 Jan 1996 10:25:53 -0600 Message-Id: <199601191625.KAA26950@convex.convex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6037; Fri, 19 Jan 96 11:25:07 EST Date: Fri, 19 Jan 96 11:25:03 EST From: "Janice C. Shepherd" To: lrr@cray.com, bleikamp@convex.convex.com, whitlock@tle.enet.dec.com, gra@epcfta.edinburgh.ac.uk Status: OR PC File: 96-006b.080 Archive: 96-006.B080 -------------------------------------------------------------------------------- NUMBER: 000080 TITLE: Vector subscripts in masked array assignment statements KEYWORDS: vector subscript, WHERE statement/construct, masked array assignment DEFECT TYPE: Erratum STATUS: Published QUESTION: Is there a restriction on vector subscripts in masked array assignments? Question 1: Is it intended to allow vector subscripts in masked array assignment statements? Question 2: If the answer to question 1 is "yes", is the intent that the following two programs are semantically equivalent; that is, should they print the same results? PROGRAM ONE INTEGER, DIMENSION(5) :: INDEX, J, K INDEX = (/ 1, 2, 3, 4, 5 /) J = (/ 1, 2, 1, 1, 2 /) K = (/ 1, 1, 2, 2, 2 /) WHERE (J == K) J(INDEX) = 0 ELSE WHERE J(INDEX) = 1 END WHERE PRINT *, J END PROGRAM TWO INTEGER, DIMENSION(5) :: INDEX, J, K LOGICAL, DIMENSION(5) :: MASK INDEX = (/ 1, 2, 3, 4, 5 /) J = (/ 1, 2, 1, 1, 2 /) K = (/ 1, 1, 2, 2, 2 /) MASK = J == K DO I = 1, 5 IF (MASK(I)) J(INDEX(I)) = 0 END DO DO I = 1, 5 IF (.NOT.MASK(I)) J(INDEX(I)) = 1 END DO PRINT *, J END ANSWER: The answer to questions 1 and 2 is yes. Discussion: Vector subscripts are allowed in masked array assignment statements. Section 7.5.3.2 describes the interpretation of vector subscripts in and in the of an . However, the interpretation of in is not completely defined. If is an array section, for example, and a nonelemental function reference occurs within a , the interpretation is not specified. The edits below correct this. REFERENCES: ISO/IEC 1539:1991 (E) section 7.5.3.2, section 6, section 6.2.2. EDITS: 1. In the second paragraph of section 7.5.3.2 after [93:29], add "or ". 2. In the third paragraph of section 7.5.3.2 after [93:34], add "or ". SUBMITTED BY: Jon Steidel LAST SIGNIFICANT CHANGE: 92-11-13 000080 HISTORY: X3J3/92-207 m123 Submitted X3J3/92-291 m123 Response, approved (UC) N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 nonpointers? 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 always apply to the allocation status of the entities, but do not apply to: (1) the values when the dummy argument or a subobject of the dummy argument has the POINTER attribute, (2) the values when the dummy argument has the TARGET attribute, is a scalar or an assumed-shape array and does not have the INTENT(IN) attribute and the actual argument is a target other than an array section with a vector subscript, and (3) the pointer association status. Edits are supplied to correct this. The answers to the specific questions are: Answer 1: Yes for the interface specified. Answer 2: Yes for the allocation status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status of the entities. No for the pointer association status. No for the values. Overlapping elements of dummy arguments may be defined during execution of SUB. Answer 4 (first part): Yes for the allocation status of the entities. No for the pointer association status of the entities. No for the value of the pointer argument. No for the value of the target argument when it is not INTENT(IN), it is scalar or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Yes for the value of the target argument in other cases. Answer 4 (second part): Upon entry to SUB, a pointer dummy argument may point to an element of a target assumed-shape dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status of the entities. No for the pointer association status of the entities. No for the values. Overlapping elements of pointer components of dummy arguments may be defined during execution of SUB. Discussion: The restrictions of Section 12.5.2.9 on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage. The latter mechanism is usually known as "copy-in/copy-out". The text assumed that the rules applied to an actual argument with the TARGET attribute, too, but defect item 125 has made it clear that this is not the case for all actual arguments with the TARGET attribute and edits are needed in 12.5.2.9. The present text is incorrect for the pointer association status of a pointer dummy argument. The implementation must allow for the pointer association status to be altered through another pointer. The present text is incorrect for the value of a pointer dummy argument. Here, the implementation must allow for the value to be altered through another pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP = 0 ! OK. This alters the value of IARGP, too. It is also incorrect where the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Here the implementation must allow for the value to be altered through a pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of IARGT, too. EDITS: 1. In section 12.5.2.9, [180:3-4] Replace the first two lines of item (1) by "No action that affects the allocation status of the entity may be taken. Action that affects the value of the entity or any part of it must be taken through the dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 2. In section 12.5.2.9, [180:32] in the line following the line "DEALLOCATE (A)" change "availability of A" to "allocation of B". 3. In section 12.5.2.9, [180:34-35] in the lines following the line "DEALLOCATE(B)" change ", but would ... attribute." to ". If B were declared with the POINTER attribute, either of the statements DEALLOCATE(A) and DEALLOCATE(B) would be permitted, but not both." 4. In section 12.5.2.9, [180:37] in the second to last paragraph on page 180, after "the same procedure" add "and the dummy arguments have neither the POINTER nor the TARGET attribute". 5. In section 12.5.2.9, [181:8] in line 8 of page 181, after "CALL SUB(B,C)" add "! The dummy arguments of SUB are neither pointers nor targets". 6. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by "If the value of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 7. In section C.12.7, [291:40-42] Replace lines 3 to 5 by "The restrictions on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage." SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 94-248 m130 Revised response and edits. 94-282r1 m130 Clarified terminology, approved u.c. 94-306 m131 ballot failed 11-7 94-309r1 m131 modified edits and answer, approved 12-1 94-366r1 m131 First edit replaced with revised text from 94-366r1 approved u.c. 95-034r1 m132 X3J3 ballot failed, 16-4 95-043 m132 revised words of answer/edit (no change in intent) and change status to X3J3 approved; approved 10-4 95-244 m134 Updated answer and edits based on new answer to defect item 125, approved u.c. 95-256 m135 X3J3 ballot failed, 10-6 95-281 m135 revised response and edits, WG5 approved 96- m136 X3J3 ballot approved, 13-3, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000082 TITLE: Host association and generic names KEYWORDS: host association, generic name DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the program fragment 1 INTERFACE F 2 FUNCTION X(Y) ... 3 CONTAINS ... 4 INTEGER F(10) 5 I = F(2) Reading in 12.1.2.2.1, Host association: Statement 4 is a containing F. Thus F is the name of a local entity and any entity of the host that has F as its nongeneric name is inaccessible (text following list on page 164). Therefore the generic name, F, in the host is accessible. With that, is F(2) in statement 5 a reference to the generic name or to the array name? ANSWER: F(2) is a reference to the array name. Discussion: The rules in 12.1.2.2.1 concern the accessibility of nongeneric names of the host. A generic identifier in the host is only available in the contained scoping unit if that identifier is established to be generic (14.1.2.4). In this particular case, F is declared as an array and is therefore not established as a procedure in the contained scoping unit. EDITS: None. SUBMITTED BY: Richard Weaver HISTORY: 92-235 Submitted 92-209 Related question submitted 93-104 m124 Response proposed and approved by unanimous consent. 93-111 m125 ballot, return to subgroup based on Maine, Rolison Weaver comments; coordinate better with section 14 93-185 m125 Original presentation of more extensive edit 93-221 m126 Incorporation of edit and slightly expanded discussion. Passed by unanimous consent. Note: 32 (see text in), 86 and 90 are dependent on approval of 82. 93-255r1 m127 ballot failed 19-5 93-257 m127 006/82 Host association and generic names (Reid) 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-1 94-160 m129 WG5 ballot approved with Rolison edit 94-184 m129 Rolison edit as requested by WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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. Edits are provided to reflect this. Discussion: 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 rules in 14.1.2.3 do not apply to the specific procedures represented by a generic intrinsic. The rules for resolving procedure references to names established to be generic are given in section 14.1.2.4.1. Section 12.3.2.3 describes the semantics of the INTRINSIC statement. An edit is supplied for this section to clarify that the name of a generic intrinsic procedure with the INTRINSIC attribute can also be the name of a generic interface. EDITS: 1. In section 12.3.2.3 add to the end of the first paragraph after the constraint [171:12]: "In a scoping unit, a name can appear as both the name of a generic intrinsic procedure in an INTRINSIC statement and as the name of a generic interface if procedures in the interface and the specific intrinsic procedures are all functions or all subroutines (14.1.2.3)." 2. In section 14.1.2.3 in the third sentence [242:28]: change "When an intrinsic procedure, operator, or" to "When an intrinsic operator or" 3. In section 14.1.2.3 add as a new paragraph at the end of the section [243:13+] "If a generic name is the same as the name of a generic intrinsic procedure, the generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure are not all functions or not all subroutines. If a generic invocation is consistent with both a specific procedure from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the interface that is referenced." SUBMITTED BY: Larry Rolison HISTORY: 92-210 m123 submitted 93-180 m125 Response, approved 19-1 93-255r1 m127 ballot failed 21-3 94-163r1 m129 Clarified answer and added another edit. withdrawn as new edit needs rewording. 94-241 m130 Sorted edits. Revised edit 1. Add edit 3. 94-290r1 m130 Revised edit 2 and deleted edit 3. Simplified discussion. Approved u.c. 94-306 m131 X3J3 ballot failed 12-7 95-196 m134 new version of edits, approved 13-2 95-256 m135 X3J3 ballot, approved 15-1 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000084 TITLE: Change masked array assignment constraint to prose KEYWORDS: masked array assignment, WHERE statement/construct, array shape DEFECT TYPE: Erratum STATUS: Published QUESTION: The first constraint following rule R743: Constraint: In each assignment-stmt, the mask-expr and the variable being defined must be arrays of the same shape. However, it may be impossible to determine that the mask-expr and the variable being defined are of the same shape at compile time. A program can be constructed quite easily in which the shapes of these entities are determined dynamically at run time. For example: INTEGER ARRAY_1(100), ARRAY_2(100), START, END READ(5,*) START, END, ARRAY_1, ARRAY_2 WHERE (ARRAY_1(START:END) .NE. 0) ARRAY_2(START:END) = & ARRAY_2(START:END) / ARRAY_1(START:END) ENDWHERE The term "shape" is defined in section 2.4.5 Array as follows: The shape of an array is determined by its rank AND ITS EXTENT IN EACH DIMENSION, and may be represented as a rank-one array whose elements are the extents. Since all constraints are intended to provide additional information to (or in some cases limit) the BNF syntax rules and are intended to be determinable at compile time, and since the extents of a mask-expr or variable in a masked array assignment can not always be determined at compile time, this constraint is in error and should be changed from a constraint to a prose restriction. ANSWER: Yes, the constraint should be changed. REFERENCES: ISO/IEC 1539:1991 (E) sections 7.5.3.1 and 7.5.3.2, in particular the first constraint following rule R743. EDIT: 1. Delete the first constraint following rule R743. [93:10-11] 2. Use the constraint body as the new first paragraph of section 7.5.3.2. [93:21] SUBMITTED BY: Larry Rolison HISTORY: X3J3/92-211 m123 Submitted, Approved uc N881 WG5 ballot approval -------------------------------------------------------------------------------- NUMBER: 000085 TITLE: Nondefault integer data type for UNIT=, RECL=, and REC= specifiers KEYWORDS: i/o UNIT=, i/o RECL=, i/o REC= DEFECT TYPE: Interpretation STATUS: Published QUESTION: Rules R902, R905, and R912 allow any type of integer for UNIT=, RECL=, and REC= respectively. Should a nondefault integer data type be allowed for these specifiers in the ? ANSWER: Yes. The standard is consistent in requiring default KIND scalar integer variables in I/O statements when values are returned to the program in such a variable. When an integer value is required as the value for an I/O specifier in any of , , , , and , but no value is returned for that specifier, then any KIND of scalar integer expression is consistently allowed. REFERENCES: ISO/IEC 1539:1991 (E) section 9.3, 9.3.4, and 9.4.1 EDITS: None SUBMITTED BY: Joanne Brixius X3J3/92-212 HISTORY: X3J3/92-212 questions submitted X3J3/92-213 questions submitted X3J3/92-243 questions submitted X3J3/92-274 m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and host association KEYWORDS: use association, host association, generic interface, EXTERNAL statement DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 the host scopes and the modules used 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.2.1 and 11.3.2. While the words used to describe the classes of accessible entities are not identical the meaning behind the words is the same. Answer 2: Entities not in the list in 12.1.2.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 the name of a potentially 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. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-214 Submitted 92-281 m123 Response proposed (11-7 was insufficient for approval) 93-030r1 Revised response proposed m124 Approved (15-1) 93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits 93-234 m126 edit replaced by that in item 82, approved uc Note: cannot go forward until 000082 does. 94-034 m128 Relying on edit in 000082 that has been removed, status changed to X3J3 consideration in progress 94-240r1 m130 Revised response with no edit, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved, with Rolison and Shepherd edits -------------------------------------------------------------------------------- NUMBER: 000087 TITLE: PARAMETER statements and SAVE statements KEYWORDS: PARAMETER statement, named constant, SAVE statement DEFECT TYPE: Erratum STATUS: Published QUESTION: Can a named constant appear in a SAVE statement? In FORTRAN 77 named constants were not allowed to appear in a SAVE statement. Fortran 90 appears to allow named constants in SAVE statements. ANSWER: No, a named constant must not appear in a SAVE statement. Edits are provided to indicate this restriction. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 5.1.2.5, 5.2.4 EDITS: 1. Change the sixteenth constraint of section 5.1 to [40:24] The SAVE attribute must not be specified for an object that is in a common block, a dummy argument, a procedure, a function result, an automatic data object, or an object with the PARAMETER attribute. 2. In section 5.1, change the first sentence of the next to last paragraph before the examples [41:9]: The presence of = implies that is a saved object, except for an in a named common block or an with the PARAMETER attribute. 3. Remove the penultimate sentence of 5.1.2.5, "The SAVE attribute ... result, or an automatic data object." [47:39] 4. Change the first constraint of section 5.2.4 to [50:9] An must not be the name of an object in a common block, a dummy argument name, a procedure name, a function result name, an automatic data object name, or the name of an object with the PARAMETER attribute. SUBMITTED BY: Janice C. Shepherd 93-011 HISTORY: 93-011 Submitted with proposed response m124 After minor edits, adopted by unanimous consent 93-111 m125 ballot, returned to subgroup based on Maine comment 93-136r m125 revised response, adopted 18-2. 93-255r1 m127 ballot failed 21-3 93-303r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 27-0 (!) 94-094r1 m128 revised wording of edit 2, but not intent. Approved uc Moved to "ready for WG5" without objection 94-160 m129 WG5 ballot approved with edit recommended 94-175 m129 suggested edit from WG5 ballot declined N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000088 TITLE: Common block names and local names KEYWORDS: common block name, local name DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.1.2.2.1 states A name that appears in the scoping unit as (5) an object name in an entity-decl ... ... is the name of a local entity and any entity of the host that has this as its nongeneric name is inaccessible. Is this consistent with 14.1.2.1 "Common Blocks" ? ANSWER: Yes. Discussion: Section 12.1.2.2.1 states rules about host association. Host association does not apply to common block names but does apply to variables within a common block. If a common block is defined in the host scope then a variable of that common block can be accessed by host association, if no local entity makes the variable inaccessible by that name by host association. The storage units of that host common block can be accessed by means other than host association. If the scope contains its own definition of the common block then the storage units of the common block are accessible in the scope. Consider this program fragment: SUBROUTINE HOST COMMON /CC/ A,B,C ... CONTAINS SUBROUTINE INNER() COMMON /CC/ D,E,F INTEGER A,C ... Variables A and C are local to the scope of subroutine INNER. The host variables A and C are not accessible by those names by host association. However variable D is storage associated with variable A, thus the storage for variable A is accessible within subroutine INNER, but not by the name A. An edit is provided to clarify that the list in section 12.1.2.2.1 is stating those conditions under which an entity in the host is inaccessible by host association by a particular name. EDIT: In section 12.1.2.2.1 in the sentence that contains the list of items replace 'that has this as its nongeneric name is inaccessible.' with 'that has this as its nongeneric name is inaccessible by that name by host association.' [164:21] SUBMITTED BY: Dick Weaver HISTORY: 92-219 Submitted 92-324 m123 Response proposed (vote of 14-6 was insufficient for approval) 94-058 m128 New Response, approved uc 94-116 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000089 TITLE: Errors in the DATA statement description KEYWORDS: DATA statement, structure constructor DEFECT TYPE: Erratum STATUS: Published QUESTION: Does the text description in section 5.2.9 [53:4-20] of the values permitted in a DATA statement contain a recurring flaw? This description continually refers to the constant values in the list as simply "constants". According to R533 a structure constructor is allowed in the list, but it is not a constant; rather it is a constant expression. This is demonstrated by: The definition of "constant" in 2.4.3.1.2. There are only two broad categories of constants defined: named constants and literal constants. The syntax rules for "constant" (R305-R307) reinforce this definition by defining only two nonterminals: and . The description of the structure constructor in section 4.4.4 [37:10-11] states: A structure constructor whose component values are all constant expressions is a derived-type constant expression. ANSWER: Yes, there is a flaw in Section 5.2.9 in the text description of the values permitted in a DATA statement. The following edits eliminate this flaw. Discussion: In considering the edits to Section 5.2.9 to repair this flaw, it became apparent that the second sentence in the third paragraph following the constraints, [53:4-5] "Each such value ... host association." applied equally to named constants and structure constructors. This means that the type definition for the structure constructor must be accessible. Furthermore, this should be stated as a constraint. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.9, 2.4.3.1.2, 3.2.3, 4.4.4 EDITS: 1. Add a new constraint after the second constraint following R537: [52:25] If a DATA statement constant value is a named constant or a structure constructor, the named constant or derived type must have been declared previously in the scoping unit or made accessible by use or host association. 2. Delete the second sentence in the third paragraph following the constraints [53:4-5], "Each such value ...host association." 3. In the third sentence [53:6], replace "following constant" with "following constant value". 4. In the next paragraph, second sentence [53:11], change "constant" to "constant value". 5. In the following paragraph, last sentence [53:17], change "constant" to "constant value". 6. In the sixth paragraph [53:18-19], change "value of the constant" to "constant value" (twice) SUBMITTED BY: Larry Rolison - X3J3/92-221 HISTORY: 92-221 m123 Submitted 93-032 m124 Draft response 93-032r1 m124 Revised based on comments from Rolison, adopted uc 93-111 m125 ballot accepted with Maine edit (assumed done at m125) 93-150 m125 Edits from X3J3 ballot 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000090 TITLE: Subroutine and function names in nested scopes KEYWORDS: procedure names, nested scopes, internal procedures, names - class, derived type DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 12.1.2.2.1 indicates A name that appears in the scoping unit as (2) a in a ... (3) a in a ... 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 names 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 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. Component names local to those derived-type definitions are accessible in the host scope. 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 the list specified in section 12.1.2.2.1: [164:3-7] Delete items (1), (3) and (4) and renumber the rest. 3. In the list specified in section 12.1.2.2.1: [164:4] change: "A in a , in a , or" to: "A in a or" 4. In section 12.1.2.2.1 ahead of the sentence "Entities that are local (14.1.2) to a procedure are not accessible to its host." add: [164:22] "If a scoping unit contains a subprogram or a derived type definition, the name of the subprogram or derived type is the name of a local entity. Any entity of the host of this scoping unit that has a nongeneric name that is the same as the name of the subprogram or derived type is inaccessible." 5. At the end of the last sentence of section 14.1.2 add: [242:13] "except in the following cases: (1) The name that appears as a in a has limited use within the scope established by the . It can be used to identify recursive references of the subroutine or to identify the name of a common block (the latter is possible only for internal and module subroutines). (2) The name that appears as a in a has limited use within the scope established by that . It can be used to identify the result variable, to identify recursive references of the function, or to identify the name of a common block (this last use is possible only for internal and module functions). (3) The name that appears as an in an has limited use within the scope of the subprogram in which the appears. It can be used to identify the name of a common block (if the ENTRY statement is in a module subprogram), to identify recursive references, or if the subprogram is a function to identify the result variable." SUBMITTED BY: Dick Weaver, X3J3/92-220 HISTORY: 92-220 submitted 92-328 m123 first draft response in (failed) 93-107 Alternate proposal submitted m124 Action deferred because of short lead time. m125 edits per Kelble notes! m125 minutes, page 13, approved uc 93-234 m126 most edits replaced by item 82, approved uc 93-255r1 m127 ballot passed 24-0 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot failed 25-2 94-332r1 m131 edits based on 93-107, approved u.c. 95-034r1 m132 X3J3 ballot approved, 20-0 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE attribute, modules, constraints DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint are 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 ! Does the type Y now have a PRIVATE component? ! Does the function F now have a PRIVATE type? END MODULE B ANSWER: Yes, the violation of a constraint must be diagnosed when the criteria for the constraint are violated across module definitions. For example: MODULE C INTEGER :: I END MODULE C MODULE D USE C, X=>Y END MODULE D In section 11.3.2, "Use Association", the second constraint requires that the Y in module D be a public entity of module C. This example violates this constraint and diagnosis is required. However, the sample code in the question is standard conforming; thus no diagnostic is required. The constraints cited in the question do not apply because the type X is not declared to be private in the module A, where X is defined. The type X is public. The "PRIVATE :: X" statement in module B does not change the public nature of the type X as defined in module A. The type X is not a public entity of module B, but it is still a public entity of module A. Therefore, the type Y does not have a private component and the function F does not have a private type. Defect item 161 discusses this issue in more detail and provides relevant citations. EDITS: None. SUBMITTED BY: Maureen Hoffert HISTORY: 92-225 m123 Submitted 93-024 m124 Response adopted (14-3). 93-111 m125 ballot, return to subgroup based on Hirchert comment Consider restricting constraints to "within a scoping unit" 93-137r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response, containing the opposite answer, was prepared, passed, and then withdrawn (see 93-177) 93-177 an alternate response (see 93-137) 93-220 m126 withdrawn 95-015r1 m132 revised response references interp 161. Note that this should not proceed to the next STATUS level, unless 161 is also at that level. 95-101 m133 X3J3 ballot approved, 17-1, with edits applied 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000092 TITLE: Pointer and storage association KEYWORDS: association - pointer, association - storage DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following example program: PROGRAM PROG INTEGER :: VAR COMMON /COM/ VAR VAR = 5 CALL SUB END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT PTR => TGT ... END SUBROUTINE SUB Is the pointer assignment legal? Although the entity named TGT was declared with the TARGET attribute, a storage associated entity, VAR, was not. ANSWER: The pointer assignment is legal only because PTR is declared within the scoping unit of SUB and is not accessible outside the scoping unit of SUB. Discussion: By the rules of 6.3.3.2, PTR becomes undefined upon return from SUB to the calling program. Note however that if PTR was also accessible in the scoping unit PROG and the variable VAR was not declared with the TARGET attribute, the program would not be standard conforming. The following example is not standard conforming. PROGRAM PROG INTEGER :: VAR INTEGER,POINTER :: PTR COMMON /COM/ VAR, PTR VAR = 5 CALL SUB ... END PROGRAM PROG SUBROUTINE SUB INTEGER,POINTER :: PTR INTEGER,TARGET :: TGT COMMON /COM/ TGT, PTR PTR => TGT ... END SUBROUTINE SUB After the call to SUB, PTR is pointer associated with the same storage that VAR is storage associated with. In this case, VAR must be declared with the TARGET attribute in the scoping unit PROG for the program to be standard conforming. EDITS: None. SUBMITTED BY: Len Moss HISTORY: Issue arose during Victoria (1992) WG5 meeting, while reviewing various questions concerning S20.121(27) m121 Separate request submitted following meeting 92-226 m123 Submitted 93-034r m124 Response, adopted by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000093 TITLE: Scalar pointer function results KEYWORDS: function result, POINTER attribute DEFECT TYPE: Erratum STATUS: Published QUESTION: May a scalar function result have the POINTER attribute? ANSWER: Yes. Discussion: The text that appears as the last paragraph of 5.1.2.4.3 is intended to apply to all function results even though it appears in a section titled, "Deferred-shape array". To clarify this point, the edit below moves that text to section 5.1 which has the more general title, "Type declaration statements". EDIT: 1. Delete the last paragraph of 5.1.2.4.3 [46:43]. 2. Insert the following paragraph after the second paragraph following the constraints in 5.1 [40:38+] A function result may be declared to have the POINTER attribute. SUBMITTED BY: Len Moss - X3J3/92-227 HISTORY: 92-227 m123 Submitted 93-075 m124 Proposed response, adopted by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved with Rolison edit 94-185 m129 Rolison edits from WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000094 TITLE: Functions in WRITE statement implied-DO loops KEYWORDS: implied-DO in i/o statement, i/o WRITE statement, i/o implied-do DEFECT TYPE: Interpretation STATUS: Published QUESTION: An example of an array-result function is: FUNCTION F(I) DIMENSION F(I) ... END Question 1: If this function is used in an output list with an implied-DO: WRITE(6,100) (F(I), I=1,N) Does the output list consist of N arrays of the array-result of function F(I) or does the output list consist of N array element references of F(I)? Question 2: A more complicated example is the use of a multidimensional array: FUNCTION F(I,J) DIMENSION F(I,J) ... END The function is used in an output list with an implied-DO: WRITE(6,100) ((F(I,J), I=1,N), J=1,K) Does the output list consist of N*K arrays of the array-result of function F(I,J)? Question 3: An example of a character variable-length array-result function is: FUNCTION F(I,J) DIMENSION F(I) CHARACTER(LEN=J) F ... END The function is used in an output list with an implied-DO: WRITE(6,100) ( ( F ( I, J ), I=1,N ), J=1,K ) Does the output list consist of N*K different sized arrays of varying character length function results? Question 4: Should an implied-DO loop in an output statement be restricted to a scalar function result? The DATA statement is limited to an array element, a , or a . See R536 in section 5.2.9. ANSWER: (1) The output list consists of N arrays of the array-result of function F(I). (2) Yes. (3) Yes. (4) No. REFERENCES: ISO/IEC 1539:1991 (E) sections 12.4, 12.4.2, and rule R1209. EDIT: None. SUBMITTED BY: Joanne Brixius X3J3/92-230 HISTORY: X3J3/92-230 Submitted X3J3/92-292 m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000095 TITLE: Functions in IOLENGTH implied-DO loops KEYWORDS: implied-DO in i/o statement, i/o INQUIRE statement IOLENGTH=, i/o implied-do DEFECT TYPE: Interpretation STATUS: Published QUESTION: In section, 9.6.3, the INQUIRE with IOLENGTH specifier is described. The use of implied-DO and function references in an output list impacts the INQUIRE statement that used the IOLENGTH specifier with an output list. An example of a array-result function is: FUNCTION F(I) DIMENSION F(I) INTEGER I REAL F(I) ... END Question 1 If the function is used in an output list with an implied-DO: INTEGER ISIZE INQUIRE(IOLENGTH=ISIZE) (F(I), I=1,N) Does the output list consist of N arrays of the array-result of function F(I) or does the output list consist of N array element references of F(I)? See Question 3. The function F(I) must be referenced N times to be able to determine the size of the result. The size of the function result cannot be determined by a declaration of the function in the caller. The function must be executed to determine the size of the result. Question 2: An example of a character variable-length array-result function is: FUNCTION F(I,J) DIMENSION F(I) INTEGER I,J CHARACTER(LEN=J) F ... END The function is used in an output list with an implied-DO: INQUIRE(IOLENGTH=ISIZE) ( ( F ( I, J ), I=1,N ), J=1,K ) Does the output list consist of N*K different sized arrays of varying character length function results? The actual size of the result can only be determined by executing the function. Question 3: Should an implied-DO loop in an INQUIRE statement with an IOLENGTH specifier be restricted to a scalar function result? The DATA statement is limited to an array element, a , or a . See R536 in section 5.2.9. This would allow the determination of the size of a function reference without actual execution of the function. ANSWERS: 1. The output list in the INQUIRE statement "references" the function "F" N times. Each reference returns an array valued result. This is not necessarily a reference in the sense of an actual function call. Your statement about referencing the function is not correct. An implementation is allowed to call the function if it so wishes, but is not required to do so. In the presence of an explicit interface it is possible some implementations will not call the function, or may call it fewer than N times. 2. The output list consists of N*K different sized arrays of varying length character function results. The implementation is not required to actually call the function. 3. No. REFERENCES ISO/IEC 1539:1991 (E) sections 9.6.3, 7.1.7.1 EDITS: None. SUBMITTED BY: Joanne Brixius X3J3/92-231 HISTORY: X3J3/92-231 Submitted X3J3/92-311 m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000097 TITLE: Specification expression KEYWORDS: expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: Published QUESTIONS: In section 7.1.6.2 "Specification expression": 1. In item (9) should not the restriction "defined by an ALLOCATE statement" be "allocatable" instead? That is, the ALLOCATE statement does not have to exist, it is being allocatable -- even if never allocated -- that is restricted. [79:14-15] And the same comment for pointer assignment. [79:14-15] 2. Would Item (9) be clarified if "local" were inserted before "variable"? [79:14] 3. In the text beginning "and where any subscript ..." should not "is" be "must be"? As written it states that any subscript is a restricted expression. [79:17] 4. In the text beginning "A specification expression (R509, R514, R515)... should not the "(R509, R514, R515)" be deleted? ANSWER: 1. Yes, see edits below. Edits are provided for similar problems in other sections. 2. No. 3. No, this is part of a long and complex sentence which begins on the previous page. 'Is' is the correct form and parallels the rest of the sentence and describes what a restricted expression 'is', not what a subscript is. 4. There is redundancy, but not an error. EDITS: 1. Replace 7.1.6.1 (6), in the first list, with the following: [77:24-28] (6) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) a constant expression, or b) a variable whose properties inquired about are not: 1) assumed, 2) defined by an expression that is not a constant expression, or 3) definable by an ALLOCATE or POINTER assignment statement 2. Replace 7.1.6.1 (6), in the second list with the following: [78:6-10] (6) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) an initialization expression, or b) a variable whose properties inquired about are not: 1) assumed, 2) defined by an expression that is not a initialization expression, or 3) definable by an ALLOCATE or POINTER assignment statement 3. Replace 7.1.6.2 (9) with the following: [79:11-15] (9) A reference to an intrinsic function which is: a) an array inquiry function (13.10.15) other than ALLOCATED, b) the bit inquiry function BIT_SIZE, c) the character inquiry function LEN, d) the kind inquiry function KIND, or e) a numeric inquiry function (13.10.8) and where each argument of the function is a) a restricted expression, or b) a variable whose properties inquired about are not: 1) dependent on the upper bound of the last dimension of an assumed-size array, 2) defined by an expression that is not a restricted expression, or 3) definable by an ALLOCATE or POINTER assignment statement SUBMITTED BY: Dick Weaver HISTORY: 92-233r m123 Submitted 93-086 m124 Revised edit, passed 15-2 93-111 m125 ballot, return to subgroup, based on Maine, Rolison, Weaver comments -- possible error and coordinate with 000047 93-143 m125 revised, withdrawn 93-211 m126 revised, approved uc 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000098 TITLE: subsumed by 000131 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDIT: SUBMITTED BY: Joanne Brixius X3J3/92-234 HISTORY: 92-234 Submitted 92-273r2 m123 Approved 93-071 m124 approved uc N881 WG5 ballot failed 93-165 m125 Revised following letter ballot, approved uc 93-255r1 m127 ballot failed 21-3 subsumed by 000131 -------------------------------------------------------------------------------- NUMBER: 000099 TITLE: Generic interfaces KEYWORDS: generic interface DEFECT TYPE: Interpretation STATUS: Published 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, defect item 000082. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 92-236 m123 Submitted 93-232 m126 Draft response based on edits in item 82. approved uc 93-255r1 m127 ballot passed 24-0 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved with suggested edit 94-168 m129 suggested edit from WG5 ballot declined N981 m131 WG5 approved -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: Although X3J3 agrees with the concept of the proposed change, the committee feels that the changes required will be more pervasive than simply changing the phrases cited in the Question. The changes are pervasive enough that they are best not attempted in a corrigendum to Fortran 90. Due to the late stage of processing of the draft Fortran 95 standard, the committee believes that it will not have time to adequately address these changes for inclusion in the Fortran 95 standard. Therefore, we are adding the suggested changes to a committee standing document entitled "Editorial Considerations for 9x Draft Revision X3J3/008". (Note that although the name of the document needs to be updated, the document continues to exist as a standing document to be used in the preparation of the Fortran 2000 draft standard.) The following edits will NOT be applied to the Fortran 95 draft standard. They exist in this document so that this document can be added to the 008 without loss of the work that was begun to apply the general changes noted in the Question. 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. Note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D 95-162 m133 Response revised to state the suggestions will be added to X3J3 standing document 008, passed u.c. 95-183 m134 X3J3 ballot passed 16-1 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000102 TITLE: Returned value for INQUIRE POSITION= on an empty file KEYWORDS: INQUIRE statement, i/o file position DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following two cases 1. Reading an empty sequential file OPEN ... POSITION='REWIND' ! positioned at initial point READ ... END= ! reads endfile record, positioned ! after endfile record BACKSPACE ... ! positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= 2. Writing an empty sequential file OPEN ... POSITION='REWIND' ! positioned at initial point ENDFILE ... ! write endfile record, positioned ! after endfile record BACKSPACE ... ! positioned before endfile record ! which is also the initial point INQUIRE ... POSITION= In section 9.6.1.16, "POSITION= ..." appears to imply any of the following can be returned by the INQUIRE statement in these three cases: processor dependent - since the file has been repositioned REWIND - since the file is now at its initial point APPEND - since the file is now at its terminal point Thus even for implementations that are specified to use REWIND and APPEND, rather than a processor-dependent value, the standard would seem to be ambiguous. One implementation can return "REWIND" while another returns "APPEND". Is this ambiguity intended? ANSWER: Yes. If the file has been repositioned since the OPEN statement was executed, then the value returned by INQUIRE(POSITION=...) is processor-dependent. No particular value is required to be returned, but a few values are prohibited in certain cases. The processor is free to return any value that is not specifically prohibited by section 9.6.1.16. A standard-conforming program cannot depend on a particular value being returned in this case. If an implementation chooses to return "REWIND" or "APPEND" after a file has been repositioned, the file must currently be positioned at the same point as if it had just been opened with that same value for the POSITION specifier in the OPEN statement. An implementation must not return APPEND if the file is not positioned at its terminal point or endfile record. Similarly, it must not return REWIND if the file is not positioned at its initial point. This is not the same as saying that an implementation will return APPEND when the file is positioned at its terminal point. It need not. But if it does return APPEND, then the program can be assured that the file really is positioned at its terminal point or endfile record. EDITS: None. SUBMITTED BY: Dick Weaver, 92-245 HISTORY: 92-245r2 92-245r3 93-071 m124 passed uc 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000103 TITLE: Statement Function with unreferenced dummy argument KEYWORDS: statement function DEFECT TYPE: Erratum STATUS: Published QUESTION: Consider the following example F(A,B,C)=A+B ! statement function, dummy-arg C not used in expr INTEGER C Since "C" is implicitly typed, must any later type definition (the INTEGER C in the example) confirm that typing? ANSWER: Yes (and therefore the example is nonstandard conforming). This is covered in the second constraint in Section 12.5.4. While that constraint appears to be about the scalar-expr "A+B", the last sentence, beginning "If a scalar...", applies to the dummy arguments as well (the 2nd constraint combines what should have been two separate constraints). The constraint will be split and clarified. EDIT: In section 12.5.4 split the second constraint at "If a scalar variable ..." [182:12] into a new constraint and add "dummy-arg-name," just before "scalar variable". SUBMITTED BY: Dick Weaver LAST SIGNIFICANT CHANGE: 92-11-13 000103 HISTORY: X3J3/92-249 Submitted X3J3/92-249r m123 Approved 16-3 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000104 TITLE: Rounding formatted output KEYWORDS: i/o formatted rounding, i/o G edit descriptor, i/o edit descriptors DEFECT TYPE: Interpretation STATUS: Published QUESTION 1: The standard requires floating-point values to be rounded, on output (see 10.5.1.2.1 through 10.5.1.2.4). It does not, however, say how they are to be rounded. Always rounding up and always rounding down are allowed by the standard. Was that intended? QUESTION 2: The ISO/IEC 1539:1980 semantics for G edit descriptors assume that floating-point values are rounded down. The ISO/IEC 1539:1991 semantics for G edit descriptors assume that floating-point values are rounded to nearest If those assumptions are violated, the implementation is sometimes required to print strings of asterisks for numbers that a user might think should be printed normally. If the interpretation is that implementations must always round to nearest, to which nearest value must they round in the case of a value exactly between two representable values? ANSWERS: 1. Yes. 2. No particular rounding method is required by the standard. The above analysis of the effect of this on output formatting using the G edit descriptor in a formatted write statement is correct. This change from FORTRAN 77's behavior was made in order to suggest a particular preferred implementation, namely, round to nearest. The committee believed that this change would promote portability of programs and consistency in implementations of I/O libraries, without actually requiring any particular rounding method. The standard's description for selecting between E and F editing, when the user specified a G edit descriptor, assumes that if a value to be printed is exactly between the two numbers obtained by rounding the original value up and down (to the appropriate number of decimal digits), then the magnitude of the value printed will be the absolute value of the original value rounded up. EDITS: None SUBMITTED BY: Robert Corbett, X3J3/92-268 LAST SIGNIFICANT CHANGE: ..-..-.. 000104 HISTORY: X3J3/92-268 Submitted X3J3/92-299 m123 Approved N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel evaluation of operands and arguments KEYWORDS: expression evaluation, argument - actual evaluation, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: Published QUESTION: Question 1. Does Fortran permit concurrent evaluation of operands in expressions and of actual arguments of functions? Question 2 Is the following program standard conforming? PROGRAM TEST INTEGER F,M PRINT *, F(1,M) + F(2,M) END FUNCTION F(X,M) INTEGER F,X,M M = X*X F = M+M RETURN END ANSWER: Answer 1 Yes, the standard permits a wide variety of expression evaluation models. Answer 2 No, the specific example provided is not standard conforming. Discussion: Sections 7.1.7.1, 12.4.2 and 12.5 provide information on rules for expression evaluation and argument association. Annex C section C.12.5 attempts to make it clear what was intended. The use of concurrent, parallel or "lazy" evaluation of expressions is permitted in a standard conforming Fortran processor. In the example provided in the question the PRINT statement is not standard conforming. Section 7.1.7 contains the following prohibition: The evaluation of a function reference must neither affect nor be affected by the evaluation of any other entity within the statement. EDITS: None. SUBMITTED BY: R. L. Page HISTORY: Contributions to the discussion provided by Brian Smith 92-269 (jw note) 92-327 (jw note) 93-079r1 m124 Type changed from Amendment to Interpretation m124 Approved by unanimous consent 93-111 m125 ballot accepted with Kelble, Rolison edits 94-160 m129 WG5 ballot approved with Shepherd edit 94-180 m129 Shepherd edit as per WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000106 TITLE: Multiple USE of modules; renaming rules KEYWORDS: USE statement, module, use renaming DEFECT TYPE: Interpretation STATUS: Published QUESTION: Section 11.3.2 states More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, all public entities in the module are accessible and the rename-lists and only-lists are interpreted as a single concatenated rename-list. If all the USE statements have ONLY qualifiers, only those entities named in one or more of the only-lists are accessible, that is, all the only-lists are interpreted as a single concatenated only-list. Assume the following module definition in considering the following questions. MODULE MOD INTEGER I, J, K END MODULE Question 1: If the following USE statements appear in a scoping unit, by what names are I and J accessible? USE MOD USE MOD, ONLY: X => I USE MOD, ONLY: Z => J The rules quoted above state in this case all public entities are accessible since one of the USE statements is without an ONLY qualifier. By concatenating the only-lists and rename-lists on a single rename list we have USE MOD, X => I, Z => J Is I accessible through both the name I and X, and is J accessible through both the name J and Z? Question 2: Same as question 1 without the ONLY clause. Here, all the USE statements are without ONLY clauses. USE MOD USE MOD, X => I USE MOD, Z => J Because MOD appears in a USE statement without a rename-list, are all public entities from MOD accessible by their declared name in MOD as well as any local names given in the rename-lists? That is, is I accessible by both I and X, and J accessible by both J and Z? ANSWER: In both examples, I is made accessible only as X, and J is made accessible only as Z. Discussion: The text cited in 11.3.2 allows a collection of USE statements referencing the same module to be interpreted as an equivalent single USE statement. This circumvents restrictions on list lengths that would otherwise be indirectly imposed by the source form rules on line lengths and number of continuations. In general, it is not possible to characterize the effect of such a collection as the union of the effects that each individual statement would have in the absence of the other statements. USE statements with ONLY: can be so composed but not USE statements without ONLY:, because the lists on other USE statements can limit the accessibility of entities not explicitly named in a USE statement without ONLY:. There are programming practices that can minimize the confusion this might engender: Use of multiple USE statements referencing the same module can be limited to those cases where it is required by the length of the list involved. When multiple USE statements are required, a minimum number can be used, and they can be placed one after another. If one USE statement indicates that all public entities are to be accessible (by omitting ONLY:), all can do so. The standard does not require any of these programming practices. EDIT: None. SUBMITTED BY: Jon Steidel HISTORY: 92-246 Initially drafted 92-279 Response proposed m123 vote (12-4) insufficient to approve 93-091 (jw note) 93-106 Discussion section expanded m124 Approved by a vote of (14-2) 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000107 TITLE: USE renaming of generic and specific interfaces KEYWORDS: generic name, specific name, use renaming DEFECT TYPE: Interpretation STATUS: Published QUESTION: A module contains a generic interface whose name matches the name of a specific interface defined in the interface block defining the generic interface. When the module is used, the name of the generic interface appears in a rename-list on the USE statement. Does the rename apply also to the specific interface? For example: MODULE MOD INTERFACE GEN SUBROUTINE GEN (A, B) REAL A, B END SUBROUTINE END INTERFACE END MODULE SUBROUTINE USER (X) USE MOD, RENAME => GEN ! Renames generic and specific GEN DIMENSION GEN (100) ! Legal to have local variable by name GEN? ... END SUBROUTINE ANSWER: Yes, the rename also applies to the specific name. Discussion: In the example, RENAME is the local name in USER which refers to the same entity that the name GEN refers to in MODULE MOD. The name GEN is free to be used for other purposes in USER. REFERENCES: ISO/IEC 1539:1991, sections 11.3.2 EDIT: None SUBMITTED BY: Jon Steidel HISTORY: X3J3/92-247 Initially drafted X3J3/92-282 Response proposed m123 approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000108 TITLE: Referencing disassociated pointers KEYWORDS: target, pointer association status, disassociated, array pointer DEFECT TYPE: Erratum STATUS: Published QUESTION: There are several places in the standard that refer to whether a disassociated pointer can be referenced. The places seem to be inconsistent in the restrictions they place on such references. In section 5.1.2.4.3 "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be defined, nor may any part of it be referenced except as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." In section 5.2.7 "An object that has the POINTER attribute must not be referenced or defined unless, as a result of executing a pointer assignment (7.5.2) or an ALLOCATE statement (6.3.1), it becomes pointer associated with a target object that may be referenced or defined." In section 7.1.4.1 "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer." In section 7.5.2 "A pointer must not be referenced or defined unless it is associated with a target that may be referenced or defined." In section 13.7.2 "The inquiry functions RADIX, DIGITS, MINEXPONENT, MAXEXPONENT, PRECISION, RANGE, HUGE, TINY, and EPSILON return scalar values related to the parameters of the model associated with the types and kind type parameters of the arguments. The value of the arguments to these functions need not be defined, pointer arguments may be disassociated, and array arguments need not be allocated." (1) Where exactly can a pointer that is disassociated be referenced? (2) Can array pointers that are disassociated be referenced in more places than scalar pointers that are disassociated? (3) Can a pointer with an undefined association status ever be referenced? (e.g. as the argument to the KIND intrinsic in a PARAMETER statement). ANSWER: 1. A pointer that is disassociated may never be referenced. The text cited from 5.1.2.4.3 is misleading and the text cited from 13.7.2 is incomplete. With the edit below and the edits in defect item 159, the text becomes more precise. 2. No. 3. No. A pointer with undefined association status may be the argument to the KIND intrinsic in a PARAMETER statement, but this is not considered to be a reference. The term reference is defined in the first paragraph of section 6. Discussion: The first paragraph of section 6 defines a reference to be the appearance of a data object name or subobject designator in a context that requires its value. When a pointer appears as an argument to an inquiry intrinsic function that is inquiring about argument presence, a property of the type or type parameters, or association status, its value is not required. Thus a disassociated pointer may appear in these places. A pointer with undefined association status may appear in all of these places except as an argument to the ASSOCIATED intrinsic function. REFERENCES: ISO/IEC 1539:1991 (E) Sections 5.1.2.4.3, 5.2.7, 6, 7.1.4.1, 7.5.2, 13.7.2 EDITS: 1. Replace the first two lines of the seventh paragraph of 5.1.2.4.3, "The size, bounds, and shape of the target ... association status." [46:30-33] with: "The size, bounds, and shape of the target of a disassociated array pointer are undefined. No part of such an array may be referenced or defined; however, the array may appear as an argument to an intrinsic inquiry function that is inquiring about argument presence, a property of the type or type parameters, or association status." SUBMITTED BY: Janice C. Shepherd - X3J3/92-258 HISTORY: 92-258 m123 Submitted 93-076 m124 Response, adopted by a vote of (11-3) m125 edits from X3J3 ballot 93-111 m125 ballot approved with Kelble, Leonard, Maine, O'Gara, Rolison edits. 93-150 m125 edits 94-160 m129 WG5 ballot approved N977 m131 2nd edit incorporated into 3rd edit of item 159 to avoid conflicting edits. -------------------------------------------------------------------------------- NUMBER: 000109 TITLE: Intrinsic function ASSOCIATED KEYWORDS: ASSOCIATED intrinsic DEFECT TYPE: Erratum STATUS: Published QUESTION: The description of ASSOCIATED (section 13.13.13) fails to specify that the result is scalar. Is this an oversight? Or is there some way in which an array-valued result can be returned? ANSWER: The result returned by ASSOCIATED is always scalar. The following edit makes this clear. EDIT: In 13.13.13 in the specification of the result type, add "scalar" after "default logical". [198:33] SUBMITTED BY: Graham Barber LAST SIGNIFICANT CHANGE: 92-11-13 000109 new HISTORY: X3J3/92-264 submitted X3J3/92-317 Response proposed m123 approved 18-1 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000110 TITLE: Named constant shape specification KEYWORDS: statement ordering, type declaration statement, named constant, PARAMETER statement, array shape, DIMENSION statement, attribute specification statement DEFECT TYPE: Interpretation STATUS: Published QUESTION: The standard seems inconsistent in that the following appears valid SUBROUTINE SUB ( ) REAL, PARAMETER :: R = 1 DIMENSION R (2) END while the following appears not to be SUBROUTINE SUB ( ) PARAMETER (R = 1) DIMENSION R(2) END Was this the intent? ANSWER: No, both are illegal. Discussion: Section 5.2 states, "All attributes (other than type) may be specified for entities, independently of type, by single attribute specification statements. 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 5.2.10 places the following restriction on objects named in a PARAMETER statement: "The named constant must have its type, shape, and any type parameters specified either by a previous type statement in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit." While the restriction is stated in the section titled, "The PARAMETER Statement", it applies to all objects with the parameter attribute. Objects with the parameter attribute may appear in subsequent specification expressions and initialization expressions. Because of this, the committee chose to require the shape of an object with the parameter attribute to be known before it is initialized and thus before it can appear in subsequent specification and initialization expressions. EDITS: None SUBMITTED BY: Peter Griffiths HISTORY: ui 99 (131, 120-43) (jw note) X3J3/120-100 Initially drafted X3J3/92-289 m123 Submitted m123 Approved 17-2 N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000111 TITLE: Array constructors in masked assignment statements KEYWORDS: array constructor, masked array assignment, WHERE statement/construct DEFECT TYPE: Erratum STATUS: Published QUESTION: The description of masked array assignment (section 7.5.3.2) does not specify how an array constructor referenced in such an assignment is evaluated. Is the evaluation of an array constructor controlled by the ? In particular, consider the following examples: (/ MATMUL (A, B) + 1 /) Evaluation on an element-by-element basis is not possible. (/ ((A (1 : J : I), I = 1, J), J = M, N) /) In this example, it is hard to select a particular element for evaluation. Note that unmasked evaluation of array constructors could introduce some interesting semantics; for example, consider the following two statements: where (A .NE. 0) B = 1/A (S1) where (A .NE. 0) B = (/ 1/A /) (S2) Execution of these two statements would lead to divide by zero overflow for (S2) but not for (S1)! ANSWER: No, the evaluation of an array constructor in an of a masked array assignment is not controlled by the . Discussion: The array constructor must be evaluated first, and then the assignment statement containing the array constructor is evaluated according to 7.5.3.2. An edit is supplied to clarify this. It is true that evaluation of an array constructor could cause the program to become nonstandard conforming. This is a consequence of the necessity for evaluating the array constructor without mask expression control. REFERENCES: ISO/IEC 1539:1991 (E) sections 4.5 and 7.5.3.2 EDITS: In 7.5.3.2 following the third paragraph [93:37+], insert the following paragraph: If an array constructor appears in an , the array constructor is evaluated without any masked control by the and then the is evaluated. SUBMITTED BY: Graham Barber - X3J3/92-264 HISTORY: 92-264 Submitted 92-293 m123 Proposed response failed by (10-10) 93-093 m124 Same response failed by (1-13). 93-153 m125 Opposite response approved by unanimous consent 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000112 TITLE: Sequence derived type external functions KEYWORDS: SEQUENCE, derived type, external function, function - external DEFECT TYPE: Erratum STATUS: Published QUESTION: Can an external function of sequence derived type be declared with a TYPE specification in the FUNCTION statement? For example, is the following a valid code fragment? TYPE (T) FUNCTION F () TYPE T SEQUENCE INTEGER I, J END TYPE T ... END ANSWER: Yes, the code fragment is valid, as an external function of sequence derived type can be declared with a TYPE specification in its FUNCTION statement. Discussion: The second paragraph of 12.5.2.2 indicates the only two conditions under which the attributes of a function result must be specified by specification statements within the function body. "If the function result is array-valued or a pointer, this must be specified by specifications of the name of the result variable within the function body." It was not intended that the syntax of allowing TYPE on a FUNCTION statement be limited to internal and module functions. The last sentence of the first paragraph of 5.1.1.7 should not be applied to function results. An edit is included for clarification. EDITS: Add after the last sentence of the first paragraph of 5.1.1.7: [43:23] "If the data entity is a function result, the derived type can be specified on the FUNCTION statement providing the derived type is defined within the body of the function or is accessible there by use or host association." SUBMITTED BY: Janice C. Shepherd, 92-130. HISTORY: ui 77, ui 90 (jw note) 92-298 Draft response proposed m123 (14-4) vote insufficient for approval m124 Approved by unanimous consent 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000113 TITLE: Ordering of array specification and initialization KEYWORDS: statement ordering, type declaration statement, initialization, array shape, DIMENSION statement, attribute specification statement DEFECT TYPE: Erratum STATUS: Published QUESTION: Fortran 90 requires that an array initialized via a DATA statement must have its array properties established by a previous specification expression (5.2.9). When an array is initialized via an =initialization-expr specification in a type declaration statement, however, there is no such requirement. For example, the code fragment, INTEGER :: I DATA I /2*1/ DIMENSION :: I(2) is prohibited by the standard, whereas the similar fragment, INTEGER :: I = (/1,1/) DIMENSION :: I(2) appears to be permitted. Is the lack of such a requirement when initializing an array in a type declaration statement an error in the standard? ANSWER: Yes, it was the intent of the committee that specifications in type declaration statements have the same restrictions as specifications in attribute specification statements. Discussion: 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. The edit below clarifies this intent for the initialization of arrays. EDIT: Section 5.1, add the following to the end of the fifth paragraph following the constraints [41:8]: "If the variable is an array, it must have its shape specified either in the type declaration statement or a previous attribute specification statement in the same scoping unit." SUBMITTED BY: Peter Griffiths HISTORY: 120-62 (120-LJM-2a) Initially drafted ui 96 (131, 120-39) (jw note) 92-287 Resubmitted 92-287r m123 Response rejected (8-12) 93-080 m124 Resubmitted with opposite answer, adopted (15-1) 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000114 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDIT: SUBMITTED BY: Peter Griffiths HISTORY: ui-98 (131, 120-43) (jw note) 120-99 Initially drafted 92-288 m123 Submitted, approved uc, subsequently questioned in letter ballot 93-074 m124 Revised, adopted by uc 93-228 m126 revised to make 12, 114, 134 consistent, approved uc 93-255r1 m127 ballot failed 21-3 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000115 TITLE: Multiple dummy arguments KEYWORDS: argument - dummy, local name DEFECT TYPE: Interpretation STATUS: Published QUESTION: Section 12.5.2.5 implies that a dummy argument in an ENTRY statement can also appear in the subprogram's FUNCTION or SUBROUTINE statement. That is, the following is standard conforming: SUBROUTINE S1(A,B,C) ... ENTRY SE1(A,B) ... END SUBROUTINE Does this imply that an entity can occur multiple times in a single list? For example, FUNCTION F2(A,B,A) ... END FUNCTION SUBROUTINE S3( ) ... ENTRY SE2(C,D,C) ... END SUBROUTINE ANSWER: Section 14.1.2 indicates that function F2 and subroutine S3 are invalid. Discussion: Section 14.1.2 lists named variables as a class (1) entity. The section also indicates that a name that identifies a local entity of one class must not be used to identify another local entity of the same class. When a dummy argument appears in both an ENTRY statement and a subprogram FUNCTION or SUBROUTINE statement, the name denotes the same local entity and not two different entities of the same class. In function F2 shown, the entity denoted by the first A is not the same entity as the second A. A similar statement can be made for the entities denoted by C in subroutine S3. In both cases, the fragments are attempting to use the same name for two entities of the same class and are therefore invalid. EDITS: None SUBMITTED BY: Tim Peters and Janice Shepherd LAST SIGNIFICANT CHANGE: 92-11-13 000115 new HISTORY: ui 49 (046, 048) (jw note) X3J3/92-048 (pg 27-29,30-34) Discussed in e-mail X3J3/92-295 m123 Response proposed - approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000116 TITLE: Scoping units and statement labels KEYWORDS: scoping unit, statement label DEFECT TYPE: Interpretation STATUS: Published QUESTION: Question 1: When does the scope change from the host to an inner scope? It makes a difference in determining when a label is a duplicate of another label in the same scope. Question 2: In the following example, are the labels considered duplicates thus making the program not standard conforming? PROGRAM EX1 10 INTEGER I 20 TYPE T 10 INTEGER T1 20 REAL T2 30 INTEGER T3 30 END TYPE Question 3: In the following example, are the labels not considered duplicates as the INTERFACE and END INTERFACE statements are in the host scope while the two interface bodies each have their own scope? PROGRAM EX2 10 INTEGER I 20 INTERFACE 10 SUBROUTINE S(A) 20 REAL A 30 END SUBROUTINE 10 FUNCTION F (AA) 20 REAL AA 30 END FUNCTION 30 END INTERFACE Question 4: In the following example, are the labels not considered duplicates since the internal subroutine and function are separate scoping units? MODULE 10 INTEGER I ... 20 CONTAINS 10 SUBROUTINE INNER1 ( ) 20 I = I + 1 30 END SUBROUTINE 10 FUNCTION F ( ) 20 F = 4.5 30 END FUNCTION 30 END MODULE ANSWER: Answer 1: In 2.2 a scoping unit is defined. The syntax rules for a derived type definition, a procedure interface body, and a program unit or subprogram define the extents of scoping units. Thus the TYPE, END TYPE, PROGRAM, END PROGRAM, MODULE, END MODULE, BLOCK DATA, END BLOCK DATA, SUBROUTINE, END SUBROUTINE, and FUNCTION, END FUNCTION statements define the beginning and end of such scoping units. Answer 2: The example is not standard conforming because there are duplicate labels in the scoping unit of the derived type since the TYPE statement is part of the derived type. Answer 3: The example is standard conforming and does not have duplicate labels. Answer 4: The labels for the internal subroutine and function are not considered duplicates since they are in separate scoping units. EDIT: None SUBMITTED BY: Janice C. Shepherd HISTORY: ui 70 (132/1,2) (jw note) 92-304 m123 approved by uc 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000117 TITLE: Use of MODULE PROCEDURE statement in internal procedures KEYWORDS: interface block, module procedure, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: The second constraint in section 12.3.2.1 appears to indicate that the following program fragment is not standard conforming. Is the following code fragment standard conforming? MODULE MOD CONTAINS SUBROUTINE SUB1(I) ... END SUBROUTINE SUB1 END MODULE PROGRAM MAIN USE MOD CALL INNER CONTAINS SUBROUTINE INNER INTERFACE SUB MODULE PROCEDURE SUB1 END INTERFACE ... END SUBROUTINE END PROGRAM ANSWER: Yes. The program fragment is standard conforming. Discussion: There are several defects in the second constraint of section 12.3.2.1. First, the constraint should not restrict the program fragment that is shown nor similar ones involving generic interfaces in internal procedures within module subprograms. Second, the constraint implies that an is a scope, when it is not. An edit is included to correct these defects. EDIT: Replace the second constraint in section 12.3.2.1 [167:31] with: "The MODULE PROCEDURE specification is allowed only if the has a and is contained in a scoping unit where each is accessible as a module procedure." SUBMITTED BY: Y. Yoshida HISTORY: ui 85 (132/63, 64) (jw note) 92-132 items 63,64. Question posed 92-318 m123 Response proposed, not formally considered due to a lead time problem m124 Approved uc 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000118 TITLE: Named constructs and host association KEYWORDS: construct name, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.1.2.2.1 defines when a name appearing in a scoping unit is the name of a local entity, making inaccessible any entity of the host that has the same name as its nongeneric name. Should the appearance of a name as a construct name be on the list? ANSWER: Yes. Discussion: Section 14.1.2 indicates that construct names are local entities. An edit is included to add construct names to the list in section 12.1.2.2.1. EDIT: Add new item to the list in section 12.1.2.2.1 [164:20] and adjust the list punctuation accordingly. "(16) The name of a named construct" SUBMITTED BY: Peter Griffiths LAST SIGNIFICANT CHANGE: 92-11-13 000118 new HISTORY: ui 86 (jw note) X3J3/92-132 item 68 Submitted as a request X3J3/92-319 m123 Response proposed - approved uc N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000119 TITLE: Rank of assumed-shape array KEYWORDS: array rank, array assumed-shape, array argument DEFECT TYPE: Erratum STATUS: Published QUESTION: Must the rank of an assumed-shape dummy argument match that of the corresponding actual argument? The fourth paragraph of section 12.4.1.1 indicates that if a dummy argument is a pointer, the actual argument must be a pointer and their ranks must agree. No similar statement appears to exist for assumed-shape arrays. ANSWER: Yes. The rank of an assumed-shape dummy argument must match that of the actual argument. This is implied by the statement in 5.1.2.4.2 that an assumed-shape array takes its shape from the associated actual argument array. An edit is included to clarify this restriction. EDIT: At the end of the first paragraph of section 12.4.1.1 [172:41], add: "If the dummy argument is an assumed-shape array, the rank of the dummy argument must agree with the rank of the actual argument." SUBMITTED BY: A. Meyer LAST SIGNIFICANT CHANGE: 92-11-13 000119 new HISTORY: ui 87 (jw note) X3J3/92-132 item 69 Submitted as a request X3J3/92-320 m123 Response proposed - approved uc N881 WG5 approval --------------------------------------------------------------------------------