From JANSHEP@torolab2.vnet.ibm.com Thu Nov 17 09:43:08 1994 Received: from vnet.ibm.com by dkuug.dk with SMTP id AA12822 (5.65c8/IDA-1.4.4j for ); Thu, 17 Nov 1994 20:46:20 +0100 Message-Id: <199411171946.AA12822@dkuug.dk> Received: from TOROLAB2 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9430; Thu, 17 Nov 94 14:45:31 EST Date: Thu, 17 Nov 94 14:43:08 EST From: "Janice Shepherd" To: sc22wg5@dkuug.dk Subject: defect management (94-006) X-Charset: ASCII X-Char-Esc: 29 Here are the 25 items that passed at the last X3J3 meeting (meeting 131). These items will be in the X3J3 letter ballot I'm about to issue. Please make note of these items now, as they are not yet available on the ftp server. While the ballot is an X3J3 ballot, comments from non-X3J3 members are also welcome. Thanks. Janice C. Shepherd -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: ANSWER: EDITS: 18. In section 9.3.4.8 change: 'READ specifies that the WRITE and ENDFILE statements must not refer to this connection.' to: 'READ specifies that the WRITE, PRINT and ENDFILE statements must not refer to this connection.' Rationale: The same restriction applies to the PRINT statement. SUBMITTED BY: HISTORY: 93-289 m127 submitted items 4-5 94-034 m128 X3J3 ballot item 4 approved (moved to 00000b), 5 failed 94-028 m128 additional items 6-7 94-028r1 m128 approval of items 6-7 uc 94-084 m128 correction of item 5, approved uc 94-116 m129 X3J3 ballot items 5,6,7 approved 21-2 94-165 m129 submitted item 10, approved u.c. 94-161r2 m129 submitted items 11-17, approved u.c. 94-221 m130 X3J3 ballot approved 22-1 with edit to item 17 N984 m131 WG5 approved items 5-7 and items 10-17, moved to b 94-323 m131 submitted item 18, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword, statement keyword DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the use of "keyword" in 12.4.1, page 172, 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2, page 16? In 13.10, page 188, is "keyword" the correct term (or should it be "argument keyword")? ANSWER: The term "keyword" is used for both "statement keyword" and "argument keyword" - see 2.5.2 and Annex A. Which is intended is usually clear from the context, and this is so on pages 172 and 188. Section 3.2.1 is referring only to statement keywords and would be clearer if the qualifier "statement" is added. EDITS: Page 19 section 3.2.1 [19:37-38] Change "Keywords" to "Statement keywords" twice. Rationale: 3.2.1 is not referring to argument keywords. SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. 92-164A m122 approved 17-4 ballot comments, 92-326 (jw note) m124 minutes, approved 15-2 93-111 m125 ballot approved with Kelble edits m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot 94-361 m131 answer with fewer edits proposed, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: X3J3 Draft response 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 or pointer association status of the entities, but do not apply to the values when (1) the dummy argument or a subobject of the dummy argument has the POINTER attribute or (2) the dummy argument has the TARGET attribute and does not have INTENT(IN) and the actual argument is a target other than an array section with a vector subscript. 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 or pointer association status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status or pointer association status of the entities. 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 or pointer association status of the entities. No for the value of the pointer argument. No for the value the target argument when it is not of INTENT(IN) and the actual argument is a target other than an array section with a vector subscript. Yes for the value 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 dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status or 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 allow a processor to translate a procedure on the assumption that each dummy argument is as distinct from any other entity accessible in the procedure as if it were a local entity other than a dummy argument. This allows a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument without the TARGET attribute 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 and edits are needed in 12.5.2.9. The present text is correct with respect to the "availability" of an entity associated with a dummy argument. Neither pointer assignment nor any of the statements ALLOCATE, DEALLOCATE, NULLIFY may be applied other than through the dummy argument. For example, in the code INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP => J ! Illegal the pointer assignment is not allowed because it is changing the pointer association of the actual argument. In the case of a dummy argument with the attribute POINTER or TARGET, the implementation can assume that its descriptor is distinct from any other entity accessible in the procedure. 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), 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 "Action that affects the pointer association status of the entity or any part of it (any pointer assignment, allocation, deallocation, or nullification) must be taken through the dummy argument. 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), 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' to 'pointer association status'. 3. 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". 4. 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". 5. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by "If the allocation status or pointer association status 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. 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), and the actual argument is a target other than an array section with a vector subscript. For example, in" 6. In section C.12.7, [291:40-42] Replace lines 3 to 5 by "accessible in the procedure as if it were a local entity other than a dummy argument. This allows a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument without the TARGET attribute 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-366 m131 First edit replaced with revised text from 94-366 approved u.c. -------------------------------------------------------------------------------- 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: X3J3 draft response 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:2-7] Delete items (1), (3) and (4) and renumber the rest. 3. In the list specified in section 12.1.2.2.1: [164:2-7] 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 to (14.1.2) 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 and any entity of the host that has this as its nongeneric name 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 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. -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 6.1.2 (page 63) states: A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute. A constraint following R505 (page 40) states: Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified. This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: Yes, the text from section 6.1.2 is contradicted and is in error. An edit is provided to correct the error. Discussion: The meaning of a pointer assignment must not be ambiguous, and this requires that a given data entity not have both the TARGET and POINTER attributes. The edit allows a structure to have the TARGET attribute, which conveys that attribute to the nonpointer components. The pointer components have the POINTER attribute only. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 6.1.2, 6.3.1.2 EDITS: 1.In section 6.1.2, in the last paragraph before the last example, [63:15-17] change the sentence that starts: "A structure component has the INTENT..." to: "A structure component has the INTENT or PARAMETER attribute if the parent object has the attribute. A structure component that does not have the POINTER attribute has the TARGET attribute if the parent object has the TARGET attribute." SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 cancelled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is there a conflict between the rule given in section 14.1.2, page 241, lines 29-31, and that given in section 12.3.2.1, page 168, lines 37-39, as they apply to generic and specific names? DISCUSSION: In a generic interface block, if a specific name is an external procedure, then it is a global entity. The generic name is a local entity of class 1. Section 14.1.2, lines 29-31, page 241 states: "Except for a common block name(14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." From the reference given for external function name (14.1.2.2), it appears that the exception is meant to apply only within the external function itself. From the text in 14.1.2, one might conclude that a generic name cannot be the same as one of the specific procedure names specified in the interface block. However, 12.3.2.1, page 168, lines 37-39 states explicitly that "a generic name may be the same as any one of the procedure names in the interface block..." ANSWER: The text in 14.1.2 was intended to allow this case. An edit is provided to clarify this. REFERENCES: ISO/IEC 1539:1991, sections 12.3.2.1, 14.1.2, and 14.1.2.2 EDIT: In 14.1.2, paragraph 2, line 1 [241:29], before "or" add ", an external procedure name that is also a generic name (12.3.2.1),". SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-188 m126 submitted 94-308 m131 proposed response 94-358 m131 clarified text of question, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.2.1.1 states: A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association. Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. Likewise, no USE statement could have occurred so use association does not apply. This means that if a named constant appears in the of a FUNCTION statement, the function must be a module procedure or an internal subprogram, and the named constant must exist in (be accessible from) the host scoping unit. This also means that a named constant must not appear in a of a FUNCTION statement of an interface body because an interface body does not access names via host association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable, but by the same reasoning as above, a subobject of a use associated variable can not appear in the expression. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds of the parent object." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Intrinsic Type Names KEYWORDS: conformance, intrinsic type, derived type, names - class DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Section 1.4 "Conformance", third paragraph following the list, states: For example, a standard-conforming processor may allow a nonstandard data type. Section 4.4.1 "Derived-type definition", fifth constraint following R424, states: A derived type must not be the same as the name of any intrinsic type... Suppose the program fragment TYPE ABC INTEGER XYZ END TYPE is taken to a processor that, as allowed by 1.4, has defined the nonstandard intrinsic type "ABC". Is it intended that this processor reject the program for the reason that a derived type , ABC, is the same as the name of a nonstandard intrinsic type? ANSWER: No. Vendor-specific types which behave like intrinsic types are not strictly intrinsic types, because the entire list of intrinsic types is enumerated in section 4. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: X3J3/93-209 m126 submitted X3J3/93-317 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-340 m131 Revised response submitted, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (p228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor-dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) This is processor dependent. The standard states: "If no argument is present, the processor sets the seed to a processor dependent value." [228:13] This leaves the value of the seed and the method of generating that value up to the processor. Therefore, it is not possible to say whether X = Y or not. Different processors will handle this in different ways. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDIT: In section 13.9.2 add the following text after the last sentence of the section [188:7+] "The pseudo random number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. However calls to RANDOM_NUMBER immediately after a call to RANDOM_SEED with a seed that is either SEED1 or SEED2 return the same sequence of pseudo random numbers. In particular, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function, primary DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: In section 12.5.4, the first constraint, it states: "... may be composed only of ...." does "composed" mean the primaries of that expression or does it extend to primaries of contained expressions? ANSWER: "Composed" is not defined by the standard. An edit is provided that eliminates the use of "composed". EDIT: In section 12.5.4, in the first sentence of the first constraint, replace "The may be composed only of" with "The primaries of the must be". SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted 94-341 m131 Question revised, response submitted, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming, ONLY DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 11.3.2 states: (with some formatting to better show logic, tags added to assist references): R1109 is or [ =>] Constraint: Each must be a public entity in the module. Constraint: Each must be the name of a public entity in the module. ...... 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, (a) all public entities in the module are accessible and (b) the s and s are interpreted as a single concatenated . Questions: 1. Is the syntax ambiguous? Note: R1107 is USE [,] or USE , ONLY: [] R1109 is or [ =>] R522 is or Thus in an can parse either as R1109 or R1109 -> R522 . 2. Can s and s be concatenated as a as specified in (b)? s permit "", while rename lists require " => ". ANSWER: 1. Yes. The syntax is ambiguous ("" should be changed to ""). However removal of the ambiguity will be deferred to the next revision of the standard (Fortran 95). 2. No. Rename and only lists cannot be concatenated as a , however the "renames" in both lists can. An edit is supplied to correct this. Discussion : There are many other places in the standard besides R1109 where the same interpretation can be reached by more than one path through the syntax (e.g. could be removed from R533 since it is a special case of a ). Rather than fix this one ambiguity now, it will be deferred to the more general clean up in Fortran 95. Note that in Fortran 95 the appropriate edits to remove the ambiguity in R1109 are : 1. In section 11.3.2, R1109 [158:11] change "" to "" 2. In section 11.3.2, the first constraint following R1109 [158:13] change "" to "" 3. In section 11.3.2, paragraph beginning "A USE statement" [158:19] change "s" to "s" EDITS: In section 11.3.2, paragraph beginning "More than one" [158:22-23] change "s and s" to "s and renames in s" SUBMITTED BY: Dick Weaver HISTORY: 93-265 m127 submitted 93-305 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 failed WG5 ballot 94-352 m131 revised response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In many computers today the range of values for integer types is not symmetric. Consider, for example, a machine with 8-bit integer arithmetic (to keep the numbers small). The integer range would typically be -128 to +127 Given an implementation that specifies an integer type with that range, do the following statements conform to Fortran 90? DATA I /-128/ I = - 128 ANSWER: The data statement is valid. r530 is ... / / r532 is ... r533 is ... and -128 is a signed integer constant in the integer range that was described. The assignment statement is NOT VALID. r735 is = following the expr syntax, we eventually find r710 is ... - r701 is r305 is ... r306 is Thus the - is an operator, 128 is an , but is out of range and, therefore, the statement is not valid. Constraining of constants to the range of values is described in 4.0. "Intrinsic data types are parameterized. In this case the set of values is constrained by the value of the parameter ..." and "An example ... is the integer data type. This data type has a processor-dependent set of integer numeric values, each of which is denoted by ..." A program is not standard-conforming if it contains references to integers that are outside the range specified by the processor (1.4). While a standard-conforming processor must detect the use of kind type parameters not supported by the processor, it need not detect the use of integers outside the range of a supported kind. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-277 m127 submitted 94-329r1 m131 response, approved 16-1 -------------------------------------------------------------------------------- NUMBER: 000161 TITLE: Modules and private derived types KEYWORDS: module, private, derived type definition, structure component DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In compiling Bert Buckley's Fortran-90 algorithms that he made available recently the following issue came up : Section 4.4.1 (p 34) states: The accessibility of a derived type may be declared explicitly by an access-spec in its derived-type-stmt or in an access-stmt (5.2.3). The accessibility is the default if it is not declared explicitly. If a type definition is private, then the type name, the structure value constructor (4.4.4) for the type, any entity that is of the type, and any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. Applying this to the following code : MODULE M1 PRIVATE TYPE FRED INTEGER F1,F2 ENDTYPE FRED TYPE(FRED),PUBLIC,PARAMETER :: Y=FRED(1,2) TYPE(FRED),PUBLIC :: X END it can be seen that entities X and Y are accessible only within module M1. Therefore specifying the public attribute for X and Y is an error. So far so good? Now what about this code : MODULE M2 TYPE FRED INTEGER F1,F2 ENDTYPE FRED END MODULE M3 USE M2 PRIVATE TYPE(FRED), PUBLIC :: X END In module M3, the public type FRED imported from M2 becomes private. Is the declaration of X illegal here? I think the text in 4.4.1 is inadequate to cover this scenario. I believe the declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. I think the standard was thinking of the M1 case not the M3 case. The problem as I see it is that module M2 contains the definition of the public type FRED and the module M3 contains the "definition" of the private type FRED. ANSWER: The declaration of X in the module M3 is standard conforming. The questioner correctly points out that the answer depends on the interpretation of what it means for a module to "contain a definition" of a type. The second paragraph of section 4.4.2 states: Two entities have the same type if they are declared with respect to the same type definition. The definition may be accessed from a module... This wording implies that module M3 does not contain a definition of the type FRED; it accesses the definition contained in module M2. Thus, it is the accessibility of FRED in module M2 that is referred to by the cited paragraph in 4.1.1. In section 11.3.2, the last paragraph before the examples singles out the public and private attributes as different from all other attributes in that they can be respecified in a module that accesses an entity by use association. This paragraph also gives an interpretation to such respecification, stating in part: If the name appears in a PRIVATE statement in a module, the entity is not a public entity of that module. Note specifically the phrase "of that module." The entity in question is still a public entity (of the module where it was defined). Nothing in any scoping unit other than the one where it was defined can change that. The effect of a PRIVATE statement in a module that accesses the entity by use association is just to prevent the "export" of the entity from that module - not to make the original entity private. The entity can still be accessed by USEing the original module where it was defined. Only in the original module containing the definition does the private attribute have the additional interpretation of actually making the entity private. It cannot actually be a private entity of any other module; note that the sentence quoted from section 11.3.2 avoids using such wording, using instead the more awkward negative statement that it is not a public entity of that module. DISCUSSION: A similar interpretation applies to the 4th constraint after R424 in section 4.4.1: 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. If the type of a component is accessed by use association, then it must have been public in the module that defined it, so this constraint does not apply. The module MODULE M4 USE M5 PRIVATE PUBLIC X END MODULE M4 is always legal if X is a public entity of M5. Suppose that M5 is MODULE M5 USE M6 TYPE JOE TYPE(RALPH) :: J1 END TYPE TYPE(JOE) :: X END MODULE M5 If the constraint in section 4.4.1 were interpreted differently, then module M4 would have to declare at least JOE and RALPH to be public. It might conceivably also need to declare other names to be public; we cannot tell without examining at least module M6 and possibly other modules used in turn. This dependence on the details of the used modules would make an "object-oriented" style of programming difficult. Module m4 does not have any obvious reason for needing to depend on the detailed structure of the type of X. Note that a module can declare an object to be public when the type of the object is not even accessible in the module. For example MODULE M7 USE M5, ONLY :: X PRIVATE PUBLIC X END MODULE M7 Nowhere is there any restriction against this. Considering that module M7 is standard conforming, it would be strange if adding a "USE M5, ONLY: JOE" suddenly made the "public X" statement nonconforming. EDIT: None SUBMITTED BY: G. Barber HISTORY: 93-290 m127 submitted 94-322 m131 answered, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization, subobject, expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can an initialization expression include arbitrary expressions for subscript or substring values if that subscript or substring value is not needed to evaluate the initialization expression? Consider the following example SUBROUTINE XX() CHARACTER *10 TEXT(20) INTEGER, PARAMETER:: I = LEN(TEXT(B+I+FNC(R))) INTEGER B, FNC ALLOCATABLE R(:) .... END SUBROUTINE The subscript of 'TEXT' is not relevant to the evaluation of the inquiry 'LEN'. There appears to be no restrictions in the standard against specifying such an arbitrary expression for the subscript. Note that with the definition of 'restricted expression' there is text [79:17-18] that indicates that any subscript, section subscript, substring starting point, or substring ending point must be a restricted expression. It would seem advisable to have an equivalent statement with the definition of an initialization expression. Section 7.1.6.1 indicates that with a subobject of a constant any subscript, must be an initialization expression (77:36-37). This restriction does not apply to this example as 'TEXT' is not a constant, so 'TEXT(B+I+FNC(R))' is not a subobject of a constant. ANSWER: No. The subscripts, section subscripts, substring starting points and substring ending points in an initialization expression must also be initialization expressions. Discussion: The restrictions for the subscripts, section subscripts, substring starting points and substring ending points as specified for subojects of constants in constant expressions and initialization expressions should also have been applied to variables that are subobjects. Edits are supplied to correct this oversight. The code fragment shown in the question is not standard conforming. EDITS: 1. Section 7.1.6.1, in item (1) of the first list [77:17-18] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' to: 'constant,' 2. Section 7.1.6.1. in the last item of the first list [77:29] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the first list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [77:29+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is a constant expression.' 4. Section 7.1.6.1, in item (1) of the second list [77:36-37] change: 'constant where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression,' to: 'constant,' 2. Section 7.1.6.1. in the last item of the second list [78:11] change: '.' to: ',' 3. Section 7.1.6.1 at the end of the second list, in the style similar to the 'and where ...' at the end of the list in 7.1.6.2: [78:11+] add: 'and where each subscript, section subscript, substring starting point, and substring ending point is an initialization expression.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-286 m127 submitted 94-333 m131 proposed response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: USE ONLY and NAMELIST KEYWORDS: use association, i/o namelist, ONLY, host association DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If a scoping unit accesses a namelist group name by use association must all the namelist group objects also be accessible in the scoping unit? Consider the following example MODULE M1 NAMELIST /N/ I,J,K END MODULE USE M1, ONLY: N, I ... WRITE(10,N) The section in the standard on the NAMELIST statement (5.4) indicates that a namelist group name must not be PUBLIC if any of its namelist group items have the PRIVATE attribute. But in this example the namelist group name and each of its namelist group items have the PUBLIC attribute. Within the program only the namelist group name and one of its three namelist items are accessible. ANSWER: No. A namelist group name accessed by host or use association may be referenced even if all the namelist group items are not accessible by host or use association. Discussion: There is no restriction in the standard on the use of a namelist group name that is accessed by host or use association even if some or all of its namelist group objects are not accessible in the scoping unit. The code fragment in the question is standard conforming as is the following code fragment: PROGRAM HOST NAMELIST /N/ I,J,K I = 1 J = 2 K = 3 CALL INNER() CONTAINS SUBROUTINE INNER() INTEGER J ! J from the host is not accessible J = 10 ... WRITE(10, N) ... The 2nd constraint of section 5.4 is disallowing a namelist group name from being accessible outside a module if any of its namelist group objects have restrictions on their accessibility outside the module. If a module has been written such that some variables are private or have private components, the private variables or private components should not be accessible outside the module indirectly through a namelist group name. The 'ONLY' keyword on a USE statement is for limiting access to mainly avoid name conflicts in the scoping unit. It is not intended to restrict all means of access to a publicly accessible entity. In both examples, the namelist items that appeared in the NAMELIST statements, are the data objects that are being output by the WRITE statements. EDIT(S): None SUBMITTED BY: Janice C. Shepherd HISTORY: 93-287 m127 submitted 94-330r1 m131 proposed response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Given A of type integer, real, or complex, must the expression DBLE (A) == REAL (A, KIND(0.0D0)) always evaluate to .TRUE. for each type and kind? The text that describes the 'Result Value' of DBLE in section 13.13.27 would be easier to understand if it just stated that the result has the value REAL (A, KIND (0.0D0)). ANSWER: Yes. This result, however, is not specified in the 'Result Value' text of the two functions. Where DBLE specifies 'as much precision ... as a double precision real datum can contain.', REAL specifies a 'processor-dependent approximation'. An edit is provided. EDIT: In 13.13.27 DBLE, replace the text of the 'Result Value' section with: [205:7-11] "The result has the value REAL (A, KIND (0.0D0) )." SUBMITTED BY: Dick Weaver HISTORY: 94-018 m128 submitted 94-331 m131 Included section reference in question, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The definition in 13.13.84, RANDOM_SEED, for the optional argument GET is: must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is set by the processor to the current value of the seed. There is similar text for the PUT argument. For both cases -- "set" is used in a manner that appears to specify assignment. For similar uses of "set" see DATE_AND_TIME, IBSET, and SET_EXPONENT. -- "current value" is not the same thing as "physical representation". Setting, or assignment, of a value and necessary conversions, are described in section 7.5. "physical representation", however, was more likely intended for RANDOM_SEED. -- The shape of the seed is processor dependent and the specification for both GET and PUT results in different semantics depending on whether the processor's seed is an array of default integers, an array of some other numeric type, or a scalar. Further, the descriptions of PUT "set the seed value" and GET "set ... to the current value of the seed" would appear to specify that: -- the processor must accept whatever is specified for a seed value when some values, 0 for example, are often not suitable -- PUT and GET can be used for global communication; assigning a value with PUT and later retrieving that same value with GET. 1. Is the following what was intended for GET? must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. Denoting this array by "a" and the current value of the seed by "s", TRANSFER (SOURCE=s, MOLD=a) is assigned to "a". TRANSFER hides both type and shape, assigning not the current value of the seed but the physical representation of that value independent of shape. Thus the seed can be of any type and any shape. Alternately must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is assigned the physical representation of the seed value in a processor dependent manner. 2. PUT semantics are more complicated in that the argument specified for PUT may not always be suitable as a seed. Thus while the assignment semantics currently specified may not have been intended, neither is it appropriate to specify TRANSFER semantics. Are PUT semantics processor dependent? This would allow processor seeds of any type and shape. 3. Given a value specified for PUT, can processors alter that value for use as a seed? ANSWER: 1. Yes, for GET "TRANSFER" semantics were intended, however "processor dependent" is both more general and parallels the PUT edit. 2. Yes, specifying PUT semantics as processor-dependent is correct. 3. Yes, the value supplied by PUT may be altered in constructing a seed. Edits provided in interpretation 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. Edits to the descriptions of RANDOM_SEED arguments PUT and GET are provided here. EDIT: 1. In 13.13.84, RANDOM_SEED, PUT argument, replace the last sentence (beginning "It is used by the processor ..." with [228:9]: "It is used in a processor-dependent manner to compute the seed value accessed by the pseudorandom number generator." SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. 94-221 m130 X3J3 ballot, failed 21-2 94-324r1 m131 revised response, approved 16-1 -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The standard considers (14.1.2.3) the following example to be ambiguous: INTERFACE BAD SUBROUTINE S1(A) END SUBROUTINE SUBROUTINE S2(B,A) END SUBROUTINE END INTERFACE ! BAD because it requires a single argument which disambiguates both by position and by keyword (A of S2 disambiguates by position but not by keyword; B of S2 disambiguates by keyword but not by position). Note that the above is the simplest example of unambiguous overloading which the standard disallows; other cases exist where the number of nonoptional arguments is the same, e.g. INTERFACE DOUBLE_PLUS_UNGOOD SUBROUTINE S1(I,P,A) END SUBROUTINE SUBROUTINE S2(J,A,I) END SUBROUTINE END INTERFACE where S2 takes two nonoptional integer arguments and S1 takes one nonoptional integer argument, but there is still no single argument which disambiguates between them. A third example shows an (apparently forbidden) unambiguous overloading where the number of arguments of each data type are the same: INTERFACE BAD3 SUBROUTINE S1(I,J,A,B) END SUBROUTINE SUBROUTINE S2(J,I,B,A) REAL I INTEGER A END SUBROUTINE END INTERFACE Was the overly strict nature of the disambiguation rules an unintentional oversight? ANSWER: Yes. A change is needed to the rules in 14.1.2.3 to avoid rejecting examples such as the first example shown. While the first example can be considered to have been incorrectly rejected by the text in the standard, the text necessary to avoid rejecting the other two examples is sufficiently complicated to indicate that it was specifically not included in the standard. Future versions of the standard may consider extending the language to include the second and third examples as standard conforming. The change is to allow a difference in the number of arguments of each data type to disambiguate overloads. Discussion: To allow the second and third examples it would be necessary to have text that would place an ordering relationship between the positional disambiguators and keyword disambiguators. Consider the following code fragment, which includes an ambiguous call. This code fragment must be nonstandard conforming. INTERFACE AMBIGUOUS SUBROUTINE S1(I,B,J,A) END SUBROUTINE SUBROUTINE S2(K,I,A,J) REAL:: I END SUBROUTINE END INTERFACE CALL AMBIGUOUS(3, 0.5, A=0.5, J=0) ! Cannot tell which of S1 or S2 to ! call EDITS: 1. In section 14.1.2.3, in the third paragraph [242:38] change "and at least one of them must have a nonoptional dummy argument that" to "and (1) one of them has more nonoptional dummy arguments of a particular data type, kind type parameter, and rank than the other has dummy arguments (including optional dummy arguments) of that data type, kind type parameter, and rank; or (2) at least one of them must have a nonoptional dummy argument that" and indent numbers (1) and (2) to be a sublist of list item (2); changing them to be (a) and (b) respectively. 2. In section 14.1.2.3, in the text after the example [243:10-11] change "(1)" to "(2)(a)" twice change "(2)" to "(2)(b)" twice SUBMITTED BY: Malcolm J. Cohen HISTORY: 94-281r1 m130 submitted with proposed response, approved u.c. 94-306 m131 X3J3 ballot failed 17-2 94-94-359r1 m131 revised answer to only change conformance of first example; approved u.c. -------------------------------------------------------------------------------- NUMBER: 000184 TITLE: Intent of intrinsic dummy arguments KEYWORDS: INTENT, intrinsic, argument - dummy, INTENT(IN) DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: If a specific intrinsic procedure is passed as an actual argument and an interface block is specified for the dummy procedure what should be specified for the intent(s) of the dummy argument(s) of the dummy procedure? In particular it seems that the following program: INTERFACE SUBROUTINE S(P) INTERFACE REAL FUNCTION P(R) REAL R ! S1 REAL,INTENT(IN) :: R ! S2 REAL,INTENT(INOUT) :: R ! S3 REAL,INTENT(OUT) :: R ! S4 END FUNCTION END INTERFACE END SUBROUTINE END INTERFACE INTRINSIC SIN CALL S(SIN) END is standard conforming if any one of the statements S1 through S4 appears for dummy argument R. Was this intended? This seems an oversight that should be corrected by an edit to 12.4.1.2 and chapter 13. ANSWER: No. Only the version of the program in which statement S2 appears is standard conforming. Discussion : Section 12.4.1.2 states that if the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure. Such characteristics (12.2) include the characteristics of the dummy arguments of which one is the argument intent. Unfortunately in chapter 13, the intents of most intrinsic procedure dummy arguments, including those of specific intrinsic functions such as SIN that may be passed as actual arguments are unspecified. The supplied edit corrects this deficiency by giving all such nonpointer dummy arguments INTENT(IN). EDITS: Add a new section 13.4 [184:1] and renumber all following sections appropriately : "13.4 Argument intents The dummy arguments of the specific intrinsic procedures in 13.12 have INTENT(IN). The nonpointer dummy arguments of the generic intrinsic procedures in 13.13 have INTENT(IN) if the intent is not stated explicitly." SUBMITTED BY: Graham Barber HISTORY: 94-275 m130 submitted 94-334r1 m131 proposed response, approved u.c -------------------------------------------------------------------------------- NUMBER: 000187 TITLE: TARGET attribute, storage association, and pointer association KEYWORDS: TARGET attribute, association - storage, COMMON block, association - pointer DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Background ---------- Interpretation Request 92, the response to which has been approved by WG5 and is now in the "B" section of interpretation requests, contains an answer that is desirable but there is no text in the standard that supports the response. X3J3 was no doubt considering the following text from section C.5.3 as the base text for the response but (1) this text is in an appendix, not in the body of the standard, and (2) the text is flawed: The TARGET attribute ... is defined solely for optimization purposes. It allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. The only part of 5.1.2.8 that could reasonably be considered the "rule" to which C.5.3 refers is: An object without the TARGET or POINTER attribute must not have an accessible pointer associated with it. This "rule" does not seem to provide the insurance mentioned in C.5.3. Rather, it seems that this sentence exists to clarify the "may" in the first sentence of 5.1.2.8. That is, it seem to be just reiterating that you can't do the following: INTEGER I INTEGER, POINTER :: P P => I In actuality, there is no way that a pointer can become *pointer associated* with an object that does *not* have the TARGET (or POINTER) attribute. The confusion seems to arise when an object with the TARGET attribute is storage associated with an object that does not have the TARGET attribute. There is pointer association and there is storage association but pointer association does not "transmit" through storage association. What, then, is the meaning of the sentence in 5.1.2.8 cited above? ANSWER: The sentence from 5.1.2.8 was intended to prohibit a nontarget object from being referenced both via a pointer and via the object's name within a single scoping unit but, as you point out, it fails to do so. Edits are provided to add text to provide the prohibition alluded to in C.5.3. Discussion: The following example is provided to illustrate the problem and clarify the edits: PROGRAM MAIN_PROG ! Variable M (a member of blank common) does not have the TARGET ! attribute. INTEGER M COMMON M INTEGER, POINTER :: P INTERFACE SUBROUTINE SUB(P) INTEGER, POINTER :: P END SUBROUTINE END INTERFACE CALL SUB(P) M = -1 PRINT *, "M = ", M PRINT *, "P's target = ", P END SUBROUTINE SUB(P) INTEGER, POINTER :: P ! Variable M (a member of blank common) has the TARGET attribute. INTEGER, TARGET :: M COMMON M M = 100 P => M END In the main program, the storage unit represented by M and P is accessible by two different methods: the variable name M and the pointer P. The text in C.5.3 is intended to prevent this multiple accessibility but the sentence it is referencing in 5.1.2.8 is not relevant with respect to this example. Pointer P is not pointer associated with variable M in the main program. This could be demonstrated by adding the statement PRINT *, ASSOCIATED(P, M) to the main program but this statement would be invalid because M has neither the POINTER nor TARGET attribute in that scoping unit. Since there is no text in 5.5.2.3 that states that if an item in a common block has the TARGET attribute, it may correspond only with another item (in another declaration of the common block) that also has the TARGET attribute, the edits add this rule. Note that Interpretation Request 160 also quotes this same passage from C.5.3 in its question. That Interpretation Request resulted in the addition of a constraint that prohibits an object in an EQUIVALENCE list from having the TARGET attribute. Without this prohibition, there could again possibly be more that one avenue of reference to a data object in a single scoping unit. In the common block case, however, it is desirable to allow variables with the TARGET attribute so the edit adds the rule stating if a variable in a common block has the TARGET attribute, any corresponding variable in another instance of the common block with the same name must also have the TARGET attribute. REFERENCES: ISO/IEC 1539:1991 5.5.1 (as modified by Interpretation Request 160) EDIT(S): 1. Delete the second sentence of 5.1.2.8 [48:16-17]. 2. Insert as the (new) last paragraph of 5.5.2.3 [59:42+]: "An object with the TARGET attribute must become storage associated only with another object that has the TARGET attribute." 3. Delete the fourth sentence of C.5.3 [269:23-25]. SUBMITTED BY: Larry Rolison HISTORY: 94-299r1 m131 submitted, with proposed response -------------------------------------------------------------------------------- NUMBER: 000188 TITLE: Ambiguity in Namelist Input? KEYWORDS: i/o namelist, value separator, logical value DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Suppose a namelist input list contains a logical array, followed by a variable named F (or T). If there are not enough elements to satisfy the array, then the standard doesn't seem clear whether to interpret the F= as .FALSE., discarding the '=' as superfluous, or as a new namelist group object. e.g, this input file contains 3 forms of .false. for a 4 item array. PROGRAM TEST IMPLICIT NONE INTEGER F(4) LOGICAL L(4) NAMELIST /TRACERS/ L, F READ (9, TRACERS) END --------------- input file ----------------- &TRACERS L=.FALSE.,.F.,F, F=0,1,2,3, &END -------------------------------------------- 10.9.1.2, 3rd paragraph (page 152) says "When the name in an input record represents an array variable.....The number of values following the equals must not exceed the number of list items in the expanded sequence, but may be less; in the latter case the effect...." so we don't need a full list. 10.9.1.3 3rd paragraph (page 153) says "When the next effective item is of type logical, the input form of the input value must not include slashes, blanks, or commas among the optional characters permitted for L editing(10.5.2) " and points to the description of the input field 10.5.2 2nd paragraph (page 143) says "The input field consists of optional blanks, optionally followed by a decimal point, followed by T for true of F for false. The T or F may be followed by additional characters in the field. Note that the logical constants .TRUE. and .FALSE. are acceptable input forms......" describes the forms allowed on input. The 'additional characters' is the sticky point. This leads to the questions: Question 1) In the example above, is the F=0 interpreted as a .false. or a namelist group item? Question 2) Does the answer to (1) change if the equals sign is surrounded by blanks (value separators) eg: &TRACERS L=.FALSE.,.F.,F, F = 0,1,2,3, &END Question 3) It appears the 3rd paragraph in 10.9.1.3 taken with 10.5.2 is intended to allow F in a list to be interpreted as .FALSE., (eg: F,) but it is difficult to construe the text this way. If the input file was &TRACERS L=.FALSE.,.F.,F/ F = 0,1,2,3, &END would the slash terminate the namelist input or would 'F/' be an illegal logical field? Shouldn't the paragraph be rewritten to say blank, comma or slash in a logical field are interpreted as value separators? Note: the consequence to the implementation is lookahead at inconvenient moments. ANSWER 1: It is intended to be interpreted as the start of a new namelist name-value subsequence. The name before the "=" may be any name in the namelist-group-object-list. Edits are supplied to resolve the ambiguity. ANSWER 2: No. The presence of optional blanks as described in section 10.9 does not affect the interpretation. ANSWER 3: The "/" terminates the namelist record. "/" is not permitted as one of the optional characters following the "T" or "F" in a logical constant (10.9.1.3, 3rd paragraph). Therefore, the "/" is a value separator (10.9, 10.8) and it causes termination of the namelist input statement as described in the 4th paragraph of section 10.9.1.2. Discussion: The committee intended that a name-value subsequence should always be identifiable by looking for an object name or subobject designator, followed by an equal sign, with optional blanks permitted before and after the equal sign. The committee attempted to eliminate all ambiguities between the start of a name-value subsequence and a value by limiting the forms of acceptable input values. The particular case mentioned in Question 1 was overlooked. The edit below fixes this ambiguity. EDIT(S): In section 10.9.1.3, 3rd paragraph [153:12], change "blanks," to "blanks, equals,". SUBMITTED BY: David Phillimore. HISTORY: 94-298 m131 submitted 94-345 m131 response, approved u.c -------------------------------------------------------------------------------- NUMBER: 000189 TITLE: Module name / local name conflict KEYWORDS: name - class, use association, global entity DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: The question in this Interpretation Request is a variation on Interpretation Request 127. Consider the following program: MODULE M1 INTEGER I END MODULE MODULE M2 USE M1 INTEGER J END MODULE MODULE M3 USE M2 INTEGER M1 END MODULE Is there a conflict between the global module name M1 (the first module) and the locally declared variable name M1 (in the last module)? ANSWER: No. Discussion: The declaration of the local variable M1 is not in conflict with module name M1 because module names are not use associated. From 11.3.2: 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. Note that a module is not a procedure. Naming a module in a scoping unit (on the USE statement) causes the module name to become known to that scoping unit (as opposed to the module name being accessed from the module) and thus conflicts with the module name are possible within the scoping unit that names the module on the USE statement. And this was the question addressed by Interpretation Request 127. However, since a module name is NOT accessed via a USE statement, module name M1 is not known to module M3 and therefore there is no conflict with the declaration of variable M1 in M3. EDIT(S): None SUBMITTED BY: Larry Rolison HISTORY:94-301 m131 submitted with proposed response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following syntax rules from Section 5.2.9: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Yes, your analysis is correct. A , a , and a constant appearing in a of a DATA implied-DO can be a name (of a named constant) but not a subobject designator. Discussion: There is no intent in the standard to extend the above rules over what was provided in the FORTRAN 77 standard. So, for example, the following program fragment is not standard conforming: INTEGER, PARAMETER :: PARR(3) = (/ 1, 2, 3 /) INTEGER :: ARRAY(3) DATA (ARRAY(I), I = PARR(1), 3) / PARR(1), PARR(2)*PARR(3) / EDIT(S): None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 -------------------------------------------------------------------------------- NUMBER: 000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association, derived type DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. An edit is provided to clarify this conclusion. DISCUSSION: The first sentence in section 4.4.2 states, "a particular type name may be defined at once in a scoping unit." However, by the use of rename, it's possible for a scoping to have access to two separately defined derived types, that were originally defined the same name, by two different local names. For derived types made accessible by us association, the derived type name referred to in section 4.4.2 is in the corresponding . Edits are provided to clarify this. REFERENCES: 4.4.2 EDITS: In section 4.4.2, add the following to the end of the first paragraph: [35:39] "In addition, two derived types accessible in the same scope might be the same if one or both are accessible by use association." In section 4.4.2, after the second paragraph, add the following independent paragraph: [35:46] "Note that the criterion that the two types have the same name applies to the of the respective ." SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000194 TITLE: Statements between SELECT CASE and CASE KEYWORDS: FORMAT statement, DATA statement, SELECT CASE statement, CASE statement, INCLUDE line, statement order DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: 1. Figure 2.1 (page 11) shows that FORMAT and DATA statements may be intermixed with executable constructs but it is not clear at what points within an executable construct these statements may appear. In particular, may FORMAT and DATA statements appear between the SELECT CASE statement and the first CASE statement of a CASE construct? 2. May an INCLUDE line appear between the SELECT CASE statement and the first CASE statement of a CASE construct? ANSWER: 1. No. In general, FORMAT and DATA statements may appear in the IF, CASE and DO executable constructs because these constructs contain blocks and a block is defined (on page 95) to consist of execution-part-constructs, which in turn are defined as being made up of FORMAT and DATA statements, among others. However, the syntax rules for the CASE construct do not provide for any blocks or any other statements to appear between the SELECT CASE statement and the first CASE statement of a CASE construct. The sentence in 8.1 [95:12] that defines a block in prose is imprecise and is clarified in an edit. 2. Yes. An INCLUDE line may appear between a SELECT CASE statement and the first CASE statement of a CASE construct because an INCLUDE line is a line, not a statement. The INCLUDE file must then contain only insignificant lines (comment and blank lines) or the first statement in the INCLUDE file must be a CASE statement. EDIT: Page 95, the sentence before rule R801 insert [95:12] "and possibly FORMAT and DATA statements" between "constructs" and "that". SUBMITTED BY: Larry Rolison HISTORY: 94-383r1 m131 submitted with proposed response, approved 13-3