From janshep@watson.ibm.com Sun Oct 15 16:20:42 1995 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id QAA03636 for ; Sun, 15 Oct 1995 16:20:17 +0100 Message-Id: <199510151520.QAA03636@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5419; Sun, 15 Oct 95 11:20:01 EDT Date: Sun, 15 Oct 95 11:03:28 EDT From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: J1-K10, Hawthorne 2 tieline 863 To: sc22wg5@dkuug.dk Subject: defect items The following 31 defect items have the status "X3J3 approved; ready for WG5". They await consideration by WG5. Some of these items were included in WG5 document N1082 (items 0c, 58, 90, 91, 141, 146, 149, 161, 167, 168, 171, 183, 184, 185, 188, 189, 192 and 195). Item 194 was also in WG5 document N1082, but this version includes the fix as requested in N1112. I hope that WG5 will vote on these items at the November meeting. Any edits can then be included in corrigendum 3. I thought I should send out this file so members get a chance to ready the defect items prior to the meeting. Miles please issue a paper number for these defects, or let me know if you would prefer a list that just includes those that did not appear in N1082. Thanks. Janice To: WG5 From: Janice Shepherd Subject: Defect items with status "X3J3 approved; ready for WG5" -------------------------------------------------------------------------------- NUMBER: 00000c TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: ANSWER: EDITS: 18. In section 9.3.4.8 [117:27-28] 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. 95-034r1 m132 X3J3 ballot item 18, approved, 20-0, with edits -------------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving generic procedure references KEYWORDS: generic name, interface block, intrinsic procedure DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 92-048 pg 29-30, 34-40, 51, 52, One of the questions raised in 92-052 pg 1-3 One of the questions raised in 92-119 Initially drafted 92-157 m122 approved m129 WG5 #550 email, J Martin, 94-04-26, failed WG5 ballot 94-293 m130 change status to HOLD for 000083 HOLD for 83 ------------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword, statement keyword DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Is the use of "keyword" in 12.4.1, page 172, 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2, page 16? In 13.10, page 188, is "keyword" the correct term (or should it be "argument keyword")? ANSWER: 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 94-160 m129 WG5 ballot, failed; 94-361 m131 answer with fewer edits proposed, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 ------------------------------------------------------------------------------ NUMBER: 000083 TITLE: Extending generic intrinsic procedures KEYWORDS: generic name, intrinsic procedure, interface block, INTRINSIC attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 applies to 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 -------------------------------------------------------------------------------- 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 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE attribute, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION:Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER:Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute, and is either scalar or is an assumed-shape array. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. An earlier answer to this defect included different wording for the start of the second paragraph of edit 3: "If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript:" and did not include the paragraph: "If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent." An earlier answer to this defect included different wording for the first paragraph of edit 4. "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript." The earlier versions of edits 3 and 4, along with edits 1 and 2 were included in corrigendum 2. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute and is either scalar or is an assumed-shape array, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2. 95-177 m134 revised response and edits, approved 14-2 95-256 m135 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following program fragment: MODULE ABC INTEGER G END MODULE PROGRAM MAIN USE ABC ! Contains name ABC REAL ABC ! Contains name ABC END PROGRAM Question 1: Is a module a global entity? Question 2: In the above program fragment, the name ABC in the main program is both the name of a module and of a local entity (of class (1)). May a local entity of class (1) in a scoping unit have the same name as a module accessed by that scoping unit? Question 3: May a module be accessed in a scoping unit that also accesses a local name that has the same name as the module? Specifically, in the example below can subroutine SUB reference the variable ABC? MODULE ABC INTEGER G END MODULE PROGRAM MAIN REAL ABC ! Contains name ABC ... CONTAINS SUBROUTINE SUB USE ABC ! Contains name ABC ... END SUBROUTINE END PROGRAM ANSWER: Answer 1: Yes, a module is a global entity. Answer 2: No, a local entity of class (1) in a scoping unit must not have the same name as a module accessed by that scoping unit. Answer 3: No, a module can not be referenced in a USE statement in a scoping unit that also accesses a local name that has the same name as the module. Variable ABC is not accessible by that name in the subroutine SUB. Discussion: Discussion for Answer 1: The second sentence of Section 11 states that a module is a program unit. Section 14.1.1 defines global entities. The definition includes modules because the definition lists program units. In addition, the response to Defect Item 90 clarified the fact that a module name is a global name by changing the following text in 12.1.2.2.1 [163:39-164:1] from "A name that appears in the scoping unit as an in an is a global name..." to "A name that is declared to be an external procedure name (by an or an ), or that appears as a in a is a global name..." Discussion for Answer 2: Answer 1 established that a module is a global entity and that a module name is a global name. Section 14.1.2 states "... 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." Discussion for Answer 3: There are two general cases where a local name could conflict with a module name. The first is as follows where the local name is contained in the module itself: MODULE ABC REAL ABC END MODULE and the second is as in the specific example provided above in Question 3. Section 11.3 [157:24-26] states: "The module name is global to the executable program, and must not be the same as the name of any other program unit, external procedure, or common block in the executable program, nor be the same as any local name in the module." This means that the first case is not standard conforming. Section 14.1.2 [241:29-31] 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." The original description of host association in 12.1.2.2.1 inadvertently failed to account for module names. The response to Defect Item 90 supplies edits to rectify the omission. With those edits, 12.1.2.2.1 now clearly states that the appearance of a name as the in a prevents access by host association to an entity of the same name in the host scoping unit. EDIT: None SUBMITTED BY: Larry Rolison in X3J3/93-037 at m124. HISTORY: 93-037 m124 Submitted 93-097 m124 Draft response failed 93-148 m125 Revised response, withdrawn 93-235 m126 Revised response based on edit in item 82. approved uc 93-255r1 m127 ballot passed 24-0 HOLD per 82 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot failed HOLD per 90 95-139 m133 Revised response based on edits in Defect Item 90, draft response approved uc 95-183 m134 X3J3 ballot passed 17-0 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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. 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. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Intrinsic Type Names KEYWORDS: conformance, intrinsic type, derived type, names - class DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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. Section 4 states: "An intrinsic type is one that is predefined by the language." 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. 95-034r1 m132 X3J3 ballot approved 19-1, with edit -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function, primary DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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, [182:4] change "The may be composed only of" to "The primaries of the must be". SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted 94-341 m132 Question revised, response submitted, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 NOT VALID. r530 is ... / / r532 is ... r533 is ... r403 is [] Thus the - is the and 128 is an , but is out of range and, therefore, the statement is not valid." 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 95-034r1 m132 X3J3 ballot failed 19-1 95-141 m133 revised response approved u.c. 95-183 m134 X3J3 ballot passed 12-4 -------------------------------------------------------------------------------- NUMBER: 000161 TITLE: Modules and private derived types KEYWORDS: module, private, derived type definition, structure component DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In compiling a Fortran 90 program, the following issues came up: Question 1:Section 4.4.1 (page 34) states: "The accessibility of a derived type may be declared explicitly by an in its or in an (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 END TYPE 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. Is specifying the PUBLIC attribute for X and Y an error? Question 2:Now what about this code: MODULE M2 TYPE FRED INTEGER F1,F2 END TYPE 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 standard conforming? The text in 4.4.1 is inadequate to cover this scenario. The declaration should be illegal but it depends on what is meant by "module containing the definition" in 4.4.1. The standard appears to describe the M1 case not the M3 case. The problem appears to be that module M2 contains the definition of the public type FRED and the module M3 contains the "definition" of the private type FRED. ANSWER 1: Yes. ANSWER 2: Yes. The declaration of X in the module M3 is standard conforming. Discussion: The answer to question 2 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.4.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 using 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. 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. 95-034r1 m132 X3J3 ballot, approved 20-0; returned to subgroup for editorial changes 95-086 m132 new version after editorial changes -------------------------------------------------------------------------------- NUMBER: 000167 TITLE: Subscripts and Substrings in Initialization expressions KEYWORDS: expression - initialization, subobject, expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 subobjects 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. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000168 TITLE: USE ONLY and NAMELIST KEYWORDS: use association, i/o namelist, ONLY, host association DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 not all the namelist group items are 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. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000171 TITLE: Equivalence of DBLE(A) and REAL(A,KIND(0.0D0)) Intrinsics KEYWORDS: DBLE intrinsic, REAL intrinsic DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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. 95-034r1 m132 X3J3 ballot approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000173 TITLE: Definition of elemental intrinsic subroutine KEYWORDS: intrinsic, elemental subroutine, MVBITS DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 Section 13.2.2 defines an elemental subroutine as one that is specified for scalar arguments but may be applied to array arguments. MVBITS, 13.13.74 for example, is identified as an elemental subroutine. Section 13.2.2 asserts that, in the case of array arguments, the results are the same as would be obtained if the subroutine were applied separately to corresponding elements of each array. This assertion is true only if the input and output arguments do not overlap but there does not appear to be such a requirement. Question 1: For elemental intrinsic subroutines, is a requirement or constraint along the lines of "input and output arguments must not be associated" missing? Question 2: Alternatively, should the text about "same results" be deleted and semantics added to these subroutines similar to those for assignment? ANSWER 1: Yes. A restriction similar to the suggested restriction is missing. ANSWER 2: No. The committee decided this imposed too great a burden on Fortran processors for the functionality provided. Discussion: The text in 13.13.74 which describes the "TO" argument specifically allows FROM and TO to be the same variable (which includes s). The standard should have prohibited the FROM and TO arguments from being associated in any other way, including partial overlaps. The TO argument should also be prohibited from being associated with any other argument to MVBITS. The other intrinsic subroutines should have had similar restrictions. EDIT: Add the following sentences to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9. SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted 95-023r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot failed 10-8 95-144 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot passed 15-2 -------------------------------------------------------------------------------- NUMBER: 000175 TITLE: What is a "constant specification expression"? KEYWORDS: constant specification expression, expression - constant, specification expression - constant, expression - specification DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The term "constant specification expression" is used in several places (in two constraints following R429, for example), but nowhere defined. What is the definition of "constant specification expression"? ANSWER:A constant specification expression is a specification expression that is also a constant expression. An edit is supplied to define this term. The edit is needed to make it clear that it is not sufficient for the value of the specification expression to be fixed. For example, if IC is a named constant with value 0 and I is a dummy argument, IC*I always has the value 0, but this is not a constant specification expression. EDIT: In section 7.1.6.2, add to the paragraph ahead of R734 [79:19] "A is a specification expression that is also a constant expression." SUBMITTED BY: Dick Weaver HISTORY: 94-137 m129 submitted 95-186 m134 response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000183 TITLE: Unambiguous procedure overloading KEYWORDS: generic interface, interface - generic, argument - dummy DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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-359r1 m131 revised answer to only change conformance of first example; approved u.c. 95-034r1 m132 X3J3 ballot approved 19-1, with edit -------------------------------------------------------------------------------- NUMBER: 000184 TITLE: Intent of intrinsic dummy arguments KEYWORDS: INTENT, intrinsic, argument - dummy, INTENT(IN) DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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: 1. Change the title of section 13.3 to be [183:36] "Arguments to intrinsic procedures" 2. add the following as a new paragraph at the end of section 13.3 [183:39+] "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 95-034r1 m132 X3J3 ballot, approved 17-3; returned to subgroup for determination of edit location description 95-085 m132 Changed placement of edit so that new section was not created. -------------------------------------------------------------------------------- NUMBER: 000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It does not appear that the standard defines the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value? Given a program segment like: REAL, ALLOCATABLE, DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) Question 1: If "ISTAT" comes back non-zero, is it legal to deallocate the arrays and try to reallocate them with smaller sizes? Question 2: If instead of allocatable arrays, the variables had been pointers, is it legal to NULLIFY them? Question 3: Are the answers to questions 1 and 2 different if a single array is allocated rather than a list? Question 4: If a DEALLOCATE fails for a list, what is the allocation status of the arrays? Question 5: Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? Question 6: 6.3.1.1 might be read to mean that successful allocation makes the arrays "currently allocated" and otherwise leaves them "not currently allocated". But that's not an obvious reading of the text. In some ways I/O is similar to allocate (they both process a list of things and have a STAT= clause). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to ALLOCATE? ANSWER 1: Yes. Note that one or more of the arrays is expected to have an allocation status of "currently not allocated", due to the error which occurred. See the Discussion below. Note that this example only used allocatable arrays. If a pointer appears in a DEALLOCATE statement, its pointer association status must be defined (section 6.3.3.2). See the Discussion below. ANSWER 2: Yes. See section 14.6.2.3. ANSWER 3: No, the answers are the same. See Answer 6 below. ANSWER 4: Whether the allocation status of the array is currently allocated or not currently allocated is processor dependent. The standard does not specify what the allocation status (or pointer association status) of arrays (or pointers) specified in a DEALLOCATE statement will be when an error condition occurs during execution of a DEALLOCATE statement. ANSWER 5: For ALLOCATED, yes. For ASSOCIATED, it depends on the pointer association status of the pointer at the time the ASSOCIATED intrinsic is called. The ALLOCATED intrinsic may be called with any allocatable array whose allocation status is either currently allocated or currently not allocated. The ASSOCIATED intrinsic must not be called with a pointer whose pointer association status is undefined (section 6.3.3.2). See the Discussion below. ANSWER 6: No. The standard does not require a processor to allocate the variables specified in an ALLOCATE statement as a group; therefore, a processor may successfully allocate some of the arrays specified in an ALLOCATE statement even when that ALLOCATE statement assigned a positive value to the variable specified in the STAT= specifier. Discussion: Only when the allocation status of an array is undefined is it illegal to specify the array in an DEALLOCATE statement. The only way for an allocatable array to have a status of undefined is described in section 14.8, item (3). If an array specified in a DEALLOCATE statement has an allocation status of not currently allocated when the DEALLOCATE statement is executed, an error condition occurs as described in section 6.3.3.1. The behavior of the DEALLOCATE statement in the presence of an error condition is described in section 6.3.3. Immediately after the execution of an ALLOCATE statement, all allocatable arrays specified in that ALLOCATE statement will have a defined allocation status (either currently allocated or currently not allocated). When a pointer is specified in an ALLOCATE statement which fails (assigns a positive value to ISTAT in this example), then the pointer association status of that pointer will not be changed if the allocation failed for that particular pointer. If that pointer previously had a pointer association status of undefined, it will still have a pointer association status of undefined immediately after the ALLOCATE statement is executed; therefore, it would be illegal to specify that pointer in a DEALLOCATE statement (section 6.3.3.2) or in a call to the ASSOCIATED intrinsic (section 13.13.13), unless the allocation status of the pointer was first changed to be defined (either associated or disassociated). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 94-296 m131 submitted 95-039 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 12-6 -------------------------------------------------------------------------------- NUMBER: 000186 TITLE: Allowed values of POSITION= and STATUS= specifiers when changing BLANK= KEYWORDS: OPEN statement, POSITION= specifier, STATUS= specifier DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION 1:What values are allowed for the POSITION= specifier when an OPEN is used to "reopen" a file and change the BLANK= etc, specifiers? Section 9.3.4, page 115, lines 20+ states: "If the file to be connected to the unit is the same as the file to which the unit is connected, only the BLANK=, DELIM=, PAD=, ERR=, and IOSTAT= specifiers may have values different from those currently in effect..." QUESTION 2:What is the current value of the POSITION= specifier? QUESTION 3:Given a sequence like: OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "ZERO", POSITION="REWIND") WRITE(10 .......... are the following OPEN statements standard conforming? (Note that POSITION="ASIS" is the default for the OPEN) 1 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="REWIND") 2 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL" ) 3 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="ASIS") A simple reading of the sentence is that 1 and 2 are standard conforming and have the same effect, but that 3 is not. The surprising feature is that execution of 1 does NOT rewind the file and that attempting to explicitly leave the file ASIS via 3 is nonstandard. It's not completely obvious that 2 is standard conforming. Section 9.3.4, page 115, line 23 states the OPEN "...does not cause any change in any of the unspecified specifiers..." so this apparently means that the POSITION= specifier is still "REWIND". However, section 9.3.4.7, page 117, line 25 states that the default value for the position specifier is "ASIS". QUESTION 4:Does the OPEN "not cause any change" from the initial specification of an unspecified specifier or does it use the default for an unspecified specifier? QUESTION 5:There is a set of similar questions for STATUS. If the STATUS= is omitted on the reopen, it defaults to "UNKNOWN". Section 9.3.4.2, page 116, lines 22+ appears to allow, for example, STATUS="NEW" on the initial OPEN but then requires either STATUS="OLD" or no STATUS= on subsequent reopens. Is this correct? ANSWER:In the following answers and discussion, the following terms are used: reOPEN (reOPEN-ing, reOPEN-ed): This is used to describe an OPEN statement for a unit which is already connected to the same file. This also applies to an OPEN statement for an external unit when the FILE= specifier is absent and the unit is already connected. properties of a connection: This is used to describe properties of a connection to an external unit that may be specified in an OPEN statement, including STATUS= and POSITION=. Note that the standard defines what the POSITION property is, but not what the STATUS property is. However, the standard does describe how the status changes during the process of an open, i.e. when STATUS="NEW" is specified, the file is created and the status changes to "OLD". Both POSITION and STATUS have a "current value", that is not necessarily the "value" specified in the OPEN statement. ANSWER 1:The standard is not clear about what values are legal for the POSITION= specifier when a file is "reOPEN-ed". The intent was to always permit a POSITION= specifier with a value of "ASIS", and to permit a value of "REWIND" only if the file was currently positioned at its initial point, and a value of "APPEND" only if the file was currently positioned at its terminal point. The edits below clarify what is allowed. ANSWER 2:The phrasing of the indicated paragraph is misleading. What the committee intended was that, except for the specifiers specifically listed, a specifier may not have a value different from those currently in effect, or in the case of the POSITION= specifier, the value must not specify a different position than the current position of the file. ANSWER 3:With the edits to the standard below, the OPEN statements labeled "2" and "3" are standard conforming for the indicated example (an OPEN followed by a WRITE followed by another OPEN, all for the same unit). The OPEN statement labeled "1" is not standard conforming in this example. ANSWER 4: The OPEN specifiers which are not specified when a file is reOPENed do not act as if the "default" value was specified for those specifiers. Instead, the property of the connection associated with that specifier is not changed by the reOPEN statement. This is described in the 6th paragraph of section 9.3.4, and this overrides the more general discussion of specifiers and their default values later in this chapter. ANSWER 5: Yes. Edits are provided to clarify what values are acceptable for the STATUS= specifier when reopening a file. Discussion: It is not absolutely clear in the Fortran 90 standard exactly what values are allowed for the POSITION= and STATUS= specifiers when a file is reOPENed. The standard is not clear what the phrase "currently in effect" in the sixth paragraph of section 9.3.4 means for the POSITION= and STATUS= specifiers. The committee intended that the phrase "currently in effect" mean the property of the connection at the time of the reOPEN, not the value of the specifier in the original OPEN statement. The language used in the standard in this area was adapted from the FORTRAN 77 standard, but some additional complications introduced by some new OPEN specifiers were not adequately addressed. When an OPEN statement is reOPENing a file, the POSITION= specifier with a value of "ASIS" is always allowed. When the file is positioned at its initial point, a reOPEN statement may have a POSITION= specifier with a value of "REWIND", and if the file is positioned at its terminal point a POSITION= specifier may have a value of "APPEND". The committee believes the standard already states this, using the intended interpretation of the phrase "currently in effect" in the 6th paragraph of section 9.3.4. An edit is included below to clarify this intent. The committee originally intended that if a STATUS= specifier was present when a unit was reOPENed, the value for the STATUS= specifier should not conflict with the "current" value in effect; however, it is very difficult to discern from the text currently in the standard what is allowed and what is prohibited. Edits are provided to clarify what values may be specified for STATUS= when reopening a file. The edits below clarify what may be specified for the POSITION= and STATUS= specifiers when reOPENing a file. EDITS: 1.In section 9.3.4, sixth paragraph [115:22], change "currently in effect." to the following: 'currently in effect. If the POSITION= specifier is present in such an OPEN statement, the value specified must not disagree with the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it must be specified with a value of OLD.' 2.In section 9.3.4, add the following paragraph (note) after the 6th paragraph: [115:25+] 'Note that a STATUS= specifier with a value of OLD is always allowed when the file to be connected to the unit is the same as the file to which the unit is connected. In this case, if the status of the file was SCRATCH before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the file is still considered to have the status SCRATCH.' 3.In section 9.3.4 [116:3], delete "OLD" and add the following sentence [116:3+]: 'If the STATUS= specifier has the value OLD, the FILE= specifier must be present unless the unit is currently connected and the file connected to the unit exists.' SUBMITTED BY: Dick Hendrickson for meeting 131 HISTORY: 94-297r1 m131 submitted 95-016 m132 draft response, 95-017r1 m132 draft response, approved u.c. 95-101 m133 X3J3 letter ballot, failed 17-1 95-160 m133 revised response, approved u.c. 95-183 m134 X3J3 ballot, passed 17-0 -------------------------------------------------------------------------------- NUMBER: 000188 TITLE: Ambiguity in Namelist Input? KEYWORDS: i/o namelist, value separator, logical value DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 / -------------------------------------------- 10.9.1.2, 3rd paragraph (page 152) states: "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 a full list is not needed. 10.9.1.3 3rd paragraph (page 153) states: "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) states: "The input field consists of optional blanks, optionally followed by a decimal point, followed by a T for true or 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) e.g.: &TRACERS L=.FALSE.,.F.,F, F = 0,1,2,3 / 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., (e.g.: 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 / 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 . 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: 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 95-034r1 m132 X3J3 ballot approved 20-0, with edits -------------------------------------------------------------------------------- NUMBER: 000189 TITLE: Module name / local name conflict KEYWORDS: name - class, use association, global entity DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The question in this defect item is a variation on defect item 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. EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-301 m131 submitted with proposed response, approved u.c. 95-034r1 m132 X3J3 ballot, approved 20-0 -------------------------------------------------------------------------------- NUMBER: 000192 TITLE: Ambiguity of dummy procedures in interface bodies KEYWORDS: dummy procedures, interface bodies DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It appears that it may not be possible to identify from a procedure interface body which, if any, of its dummy arguments are dummy procedures. This arises from the fact that it is not necessary to give an explicit interface for dummy procedures, or even to specify the EXTERNAL attribute for them (the latter only being necessary for procedures that are used as actual arguments). Even if it were mandatory to (at least) specify EXTERNAL for dummy procedures, this would still not resolve them into subroutines and functions, given that typing may be implicit. For example, in: INTERFACE FUNCTION F (A,B,C) END FUNCTION F END INTERFACE each of the arguments could be a dummy scalar variable, a dummy function or a dummy subroutine. It appears that an explicit interface should identify dummy procedures and their nature (function or subroutine, and result type in the former case). Section 12.2 of the F90 standard ("Characteristics of Procedures") does not seem to give much guidance: section 12.2.1.2 states that a dummy procedure's characteristics only include its characteristics *as* a procedure if its interface is explicit, which is not very illuminating. Question 1: Should a procedure interface body unambiguously identify dummy procedures and their nature (i.e. function or subroutine)? Question 2: Is the EXTERNAL attribute mandatory for dummy procedures in an interface body, if they do not themselves have explicit interfaces? Question 3: If so, how are dummy functions and subroutines distinguished given that typing may be implicit? ANSWER: Answer 1: No. The interface body must identify each dummy argument that is a procedure by means of one of the following : -- an EXTERNAL statement for the argument -- a type declaration statement for the argument and the argument also has the EXTERNAL attribute -- an interface block for the argument. Where an interface block is present the interface body will allow the disambiguation of the dummy procedure as a subroutine or function. Where a type declaration statement is present the dummy procedure is identified as a function. Where only an EXTERNAL statement is present it is not possible to disambiguate the procedure as a subroutine or function. Answer 2: Yes. Answer 3: A dummy argument that is a procedure may be identified as a function by its appearance in a type declaration statement or in a function statement within an interface body for the argument. A dummy argument that is a procedure may be identified as a subroutine by its appearance in a subroutine statement within an interface body for the argument. Discussion: The necessity to disambiguate dummy arguments that are procedures from dummy arguments that are not procedures is described in the response to defect item 000063. Section 12.3.2.1 (page 168) states that an interface body specifies all of a procedure's characteristics. Section 12.2.1.2 indicates that the characteristics of a dummy procedure are the explicitness of its interface, its characteristics as a procedure if the interface is explicit and whether it is optional. So, if a procedure P has a dummy procedure with an implicit interface the characteristics of the dummy procedure do not include whether it is a function or subroutine. Therefore it is not necessary that an interface block for P disambiguate the dummy procedure as a function or subroutine. If by contrast the interface for the dummy procedure is explicit in the scope of P, any interface body for P must include a nested interface body for the dummy procedure. This is indicated in the standard from the text of sections 12.2, 12.2.1.2 and 12.3. Section 12.3 specifies that the characteristics of a procedure are fixed. Section 12.2 indicates that the characteristics of a procedure include the characteristics of its dummy arguments. Finally, section 12.2.1.2 states that the characteristics of a dummy procedure include the explicitness of its interface. So any interface block for P must incorporate a nested interface block for the dummy procedure that specifies all these characteristics. EDITS: None SUBMITTED BY: John Merlin HISTORY: 94-307 m131 submitted 95-054r1 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 14-4, with edits applied -------------------------------------------------------------------------------- NUMBER: 000193 TITLE: Pointer actual arguments with the OPTIONAL attribute KEYWORDS: optional, POINTER attribute TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION : Section 12.5.2.8 states the following about an optional dummy argument that is not present (as modified by Corrigendum 1): [179:39-40] "Except as noted in (5) above, it may be supplied as an actual argument corresponding to an optional dummy argument." Section 7.1.4.1 states (as modified by Corrigendum 2) : [76:20:22] "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, or as the target in a pointer assignment statement." Consider the following example : PROGRAM MAIN CALL INNER() CONTAINS SUBROUTINE INNER(PARG) OPTIONAL :: PARG POINTER :: PARG INTERFACE SUBROUTINE SUB(TARG) OPTIONAL :: TARG END SUBROUTINE END INTERFACE CALL SUB(PARG) END SUBROUTINE END PROGRAM In this example, PARG is an optional dummy argument that is not present and it is being supplied as an actual argument corresponding to an optional dummy argument. On the other hand, PARG is a pointer that is not associated with a target, therefore it should not be supplied as the actual argument corresponding to a dummy argument that is not a pointer. If a pointer dummy argument is not present, may it be specified as the actual argument corresponding to a dummy argument that is not a pointer? ANSWER : No. An optional dummy argument that is a pointer and is not present must not be supplied as an actual argument corresponding to a dummy argument that is not a pointer. This restriction should have been included in the list within section 12.5.2.8 Edits are supplied to correct this omission. EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" SUBMITTED BY: Janice C. Shepherd HISTORY: 95-097 m133 submitted, with proposed response, approved u.c. 95-183 m134 X3J3 ballot, passed 16-1 -------------------------------------------------------------------------------- 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 approved; ready for WG5 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 in section 8.1 (on page 95) to consist of s, 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 or an END SELECT statement. EDIT: Page 95, the sentence before rule R801 [95:12] insert "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 95-034r1 m132 X3J3 ballot approved 19-1, with edits 95-116 m133 (N1112) correct typo in answer 2. -------------------------------------------------------------------------------- NUMBER: 000195 TITLE: INQUIRE with preconnected files KEYWORDS: INQUIRE statement, preconnected file DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: If unit 3 is preconnected to file PDG, which does not exist, then consider the following Fortran 90 source: PROGRAM PETE CHARACTER*50 FM INQUIRE(UNIT=3, FORM=FM) END The notes (section C.9.4, page 278, lines 11-17) state that 'For a preconnected file that does not exist, a form may be established or the establishment of a form may be delayed until the file is created'. QUESTION 1: Where in the actual standard is there anything that substantiates the notes that the form may be established as a preconnection property or that it may be delayed? QUESTION 2: If a processor delays the establishment of a form until the file is created, then what is returned in variable FM in the program above? The standard does not seem to cover this case, all it covers is a) if the connection is for formatted b) if the connection is for unformatted c) if there is no connection There seem to be similar problems with INQUIRE with RECL, BLANK and DELIM specifiers on a similar file. ANSWER 1: The standard does not clearly state that the establishment of a form may be delayed. It is inferable from other text and the lack of an explicit prohibition. ANSWER 2: The standard does not specify what is returned in the variable FM in this case. Therefore, the processor is free to choose any value. Some of the other specifiers may also return processor dependent values for this example. Any property of the connection or file that depends on: 1) the "form" or "access" of the file connection, or 2) is only allowed for a file with a particular "form" or "access", may have a processor dependent value returned by the INQUIRE statement for that property, for this particular example. Discussion: In several places the standard refers to a form being in the allowed set of forms. A processor may allow (but is not required to allow) some files to be OPENed with either a FORM value of FORMATTED or UNFORMATTED. In section 9.3.4.4 (OPEN statement, FORM= specifier), the standard states: "For a new file, the processor creates the file with a set of allowed forms that includes the specified form". This implies that a processor may delay establishing a form for a file until the file is created. And in section 9.3.2, 3rd paragraph, the standard states: "A file may be connected and not exist. An example is a preconnected external file that has not yet been written (9.2.1.1)." So, a preconnected file need not exist until the file is referenced in a data transfer statement, and the establishment of the form may be delayed until the the file is created. If the processor delays establishing a form until the file is created, the first data transfer statement to reference a non-existent preconnected file will establish the form, and it is incumbent upon the user to only use that form. EDITS: None. SUBMITTED BY: Peter Griffiths HISTORY: 95-014 m132 submitted 95-018 m132 draft response, approved u.c. 95-101 m133 X3J3 ballot approved, 16-2, with edits applied -------------------------------------------------------------------------------- NUMBER: 000198 TITLE: Characteristics of dummy procedures KEYWORDS: argument - optional, characteristics, dummy procedures, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 12.4.1.2 "Argument associated with dummy procedures" states: "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 (12.2)." Section 12.2.1.2 "Characteristics of dummy procedures" states: "The characteristics of a dummy procedure are the explicitness of its interface (12.3.1), its characteristics as a procedure if the interface is explicit, and whether it is optional (5.1.2.6, 5.2.2)." This would imply that the following two examples are not standard conforming, as the characteristics of ARG1 are not the same as the characteristics of ARG2, and ARG2 has an explicit interface. Example 1: SUBROUTINE S(ARG1) EXTERNAL ARG1 INTERFACE SUBROUTINE SS(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE SS END INTERFACE CALL SS(ARG1) ! ARG2 has an explicit interface and that is ! one of its characteristics but ARG1 has an ! implicit interface as one of its characteristics END SUBROUTINE S Example 2: SUBROUTINE T(ARG1) OPTIONAL ARG1 INTERFACE FUNCTION ARG1(I) END FUNCTION END INTERFACE INTERFACE SUBROUTINE TT(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE TT END INTERFACE IF (PRESENT(ARG1)) CALL TT(ARG1) ! ARG1 is optional and that ! is one of its characteristics. ARG2 is not ! optional and that is one of its characteristics. END SUBROUTINE T Are the code fragments standard conforming? ANSWER: Yes, both code fragments are standard conforming providing in the first code fragment that ARG1 is associated with a function whose arguments and function result are consistent with those of ARG2. Discussion: In the text cited from 12.4.1.2, the reference to 12.2 was there to indicate that the requirement is that the characteristics of the dummy procedure as a procedure match the characteristics of the actual procedure as a procedure. The other characteristics of a dummy procedure (the explicitness of its interface and whether it is optional) were not meant to be included in the reference. The characteristics of a procedure are: - the classification of the procedure as a function or subroutine - the characteristics of its arguments - the characteristics of its result value if it is a function In the second code fragment the interface for ARG1 shows that these three characteristics are the same for ARG1 and ARG2. In the first code fragment these three characteristics of ARG1 are not known. For this code fragment to be standard conforming these three characteristics of any procedure associated with ARG1 must be the same as those of ARG2. An edit is included to clarify the text in 12.4.1.2. EDIT: Section 12.4.1.2, replace the second paragraph with [173:35-36] "If the interface of the dummy procedure is explicit, the characteristics listed in 12.2 must be the same for the associated actual procedure as for the corresponding dummy procedure." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-042 m132 submitted, with proposed response, approved 9-4, 95-067 m132 alternate edit proposed, approved u.c. 95-101 m133 X3J3 ballot, failed 13-5 95-187 m134 alternate response proposed, approved u.c. 95-256 m135 X3J3 ballot, approved 15-0 ------------------------------------------------------------------------------ NUMBER: 000199 TITLE: Kind Type Parameters and the DELIM= specifier KEYWORDS: kind type parameter, i/o list-directed, i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Should defect item 131, which clarified that kind parameters should not appear in formatted input and output records, have deleted the text about in section 9.3.4.9 also? ANSWER: Yes. This is corrected by the edit below. Discussion: Defect item 131 revised numerous sections in chapter 10, where the form of values in formatted records was described, but similar text in chapter 9 was missed. The intent of defect item 131 was to prohibit a from appearing as part of a nondefault character constant in formatted records. Defect item 131 should have deleted the text in chapter 9, section 9.3.4.9, in the discussion of the DELIM= specifier, where the standard states that a nondefault character constant written to a list directed or namelist output record will be preceded with a and an underscore, whenever the file was opened with certain values for the DELIM= specifier. EDITS: In section 9.3.4.9, first paragraph, delete the 4th sentence [117:40-41]: "If APOSTROPHE or QUOTE is specified, a and underscore will be used to precede the leading delimiter of a nondefault character constant." SUBMITTED BY: Rich Bleikamp HISTORY: 95-181 m134 submitted with proposed response, approved u.c. 95-256 m135 X3J3 ballot, approved 16-0 ------------------------------------------------------------------------------