From janshep@watson.ibm.com Fri Jan 19 10:20:20 1996 Received: from convex.convex.com by mozart.convex.com (8.6.4/1.28) id KAA27228; Fri, 19 Jan 1996 10:19:57 -0600 Received: from watson.ibm.com by convex.convex.com (8.6.4.2/1.35) id KAA26942; Fri, 19 Jan 1996 10:25:33 -0600 Message-Id: <199601191625.KAA26942@convex.convex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6035; Fri, 19 Jan 96 11:25:01 EST Date: Fri, 19 Jan 96 11:24:59 EST From: "Janice C. Shepherd" To: lrr@cray.com, bleikamp@convex.convex.com, whitlock@tle.enet.dec.com, gra@epcfta.edinburgh.ac.uk Status: OR PC File: 96-006b.120 Archive: 96-006.B120 -------------------------------------------------------------------------------- NUMBER: 000120 TITLE: PRESENT intrinsic and host association KEYWORDS: PRESENT intrinsic, host association DEFECT TYPE: Erratum STATUS: Published QUESTION: Can the PRESENT intrinsic be called from an internal procedure with an argument that is an optional dummy argument of its host? For example SUBROUTINE HOST(OPT) REAL, OPTIONAL :: OPT ... CONTAINS SUBROUTINE INNER ( ) IF (PRESENT (OPT) ) THEN ... ANSWER: Yes. Discussion: As long as the optional dummy argument is accessible it can be used as an argument to the PRESENT intrinsic. An edit is provided for clarification. REFERENCE: ISO/IEC 1539:1991 (E) Section 13.13.80 EDIT: Replace the description of Argument in 13.13.80 [226:17] with "A must be the name of an optional dummy argument that is accessible in the procedure in which the PRESENT function reference appears." SUBMITTED BY: Janice C. Shepherd LAST SIGNIFICANT CHANGE: 92-11-13 000120 new HISTORY: X3J3/92-321 Question and proposed response first appeared N881 WG5 approval -------------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) ; P = Q The phrase "partial statements" used in sections 3.3.1.2 and 3.3.2.2 would suggest that they are legal code fragments. It was likely the intention that the semicolon be permitted after a complete statement and (possibly) before the start of a subsequent statement. ANSWER: None of the cases are conforming. Discussion: The phrase "partial statements" used in 3.3.1.2 and 3.3.2.2 was intended to describe the strictly lexical entity resulting when a line is continued in mid-statement. A statement interrupted by continuation, and the associated portion on the subsequent line, are two partial statements. Thus it was intended that breaking a statement into two partial statements be accomplished by continuation only, and not also by the ";" separator. Edits are provided to avoid the use of the phrase "partial statements" while making more concise the intention of the standard committee. With these edits, the following are conforming examples, and cases (1), (2) and (3) are nonconforming. F = & G ; P = & ! conforming Q F = & G ; P = Q ! conforming F = G ; P = & ! conforming Q EDITS: 1. Section 3.3.1.2 [22:44-45], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context or in a comment. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line.' 2. Section 3.3.1.2 [23:1-2], eliminate the last sentence of this section (it becomes redundant with edit 1). 3. Section 3.3.2.2 [23:36-37], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context, in a comment, or in character position 6. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line, except in character position 6.' 4. Section 3.3.2.2 [23:39-40], eliminate the last sentence of this section (it becomes redundant with edit 3). SUBMITTED BY: Paul St. Pierre, 119-PSP-1 HISTORY: 119-PSP-1 (initial submission) ui 94 (jw note) 92-284 m123 considered 94-072r1 m128 new response approved uc 94-116 m129 X3J3 ballot failed 13-10 94-243r1 m130 Revised 3rd edit and revised question to be closer to original question. Approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, approved, accept Reid edit. -------------------------------------------------------------------------------- NUMBER: 000122 TITLE: Intrinsic procedures in modules KEYWORDS: intrinsic procedure, module DEFECT TYPE: Interpretation STATUS: Published QUESTION: A standard-conforming processor is permitted (1.4) to add nonstandard intrinsic procedures, even when such procedures change the meaning of an otherwise standard-conforming program. Is such a processor permitted to "package" such nonstandard intrinsic procedures into a (non-Fortran-expressible) module, so that they would only be visible in scoping units that access the module via USE association? For example, suppose a vendor provides (possibly built into the compiler) a module, WAY_COOL, containing a function named NEAT_STUFF which takes a single default integer argument and returns a default integer result. Is the vendor permitted to define NEAT_STUFF to be a nonstandard intrinsic? If so, if the following program is submitted to this processor, which version of NEAT_STUFF (the user's or the vendor's) is invoked in each subroutine? PROGRAM HOT_STUFF CALL YOURE_HOT CALL YOURE_NOT END PROGRAM SUBROUTINE YOURE_HOT USE WAY_COOL PRINT *, NEAT_STUFF(42) END SUBROUTINE SUBROUTINE YOURE_NOT PRINT *, NEAT_STUFF(43) END SUBROUTINE FUNCTION NEAT_STUFF(NOT) NEAT_STUFF = NOT END FUNCTION ANSWER: 1. Yes. A standard-conforming processor may package additional intrinsic procedures in a module, even though not expressible in Fortran, in order to facilitate control of their visibility through USE association. Section 1.4 only restricts processor extensions to not conflicting with the standard forms and relationships (and grants an exception to this restriction for intrinsic procedures). 2. Yes. A standard-conforming processor may supply an intrinsic function, such as NEAT_STUFF in the example (1.4). This would result in the vendor's (intrinsic) NEAT_STUFF being invoked in YOURE_HOT and the user's NEAT_STUFF being invoked in YOURE_NOT. A standard-conforming processor must not reserve specific module names solely for such use as a standard-conforming program may use a module with such a selected name. Note that a program invoking the vendor's intrinsic NEAT_STUFF is not standard-conforming (section 1.4). EDITS: None SUBMITTED BY: Len Moss, X3J3/93-025 HISTORY: 93-025 submitted 93-121 proposed answer (no record in minutes of processing) 93-225 m126 draft response submitted, Approved (7-4) 93-255r1 m127 ballot failed 20-4 94-024r1 m128 proposed response, approved 16-1 94-116 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: INT intrinsic DEFECT TYPE: Interpretation STATUS: Published QUESTION: Is the sentence in 13.13.47 "case (i): If A is of type INTEGER, INT(A)=A" incomplete? Specifically consider the case of A being nondefault integer kind where RANGE(A) > RANGE(INT(A)) ANSWER: No, the sentence is correct. Discussion: Case(i) does not apply when RANGE(A) > RANGE(INT(A)). The text just before the example addresses such cases: "The result is undefined if the processor cannot represent the result in the specified integer type." EDITS: None. SUBMITTED BY: Hideo Wada, Chair IPSJ/ITSCJ SC22/Fortran HISTORY: 93-036 item 3 Question posed 93-077 Response proposed m124 Approved uc 93-111 m125 ballot approved 94-160 m129 WG5 approved with Rolison edit 94-186 m129 Rolison edit as per WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000124 TITLE: Result of LBOUND for assumed-size arrays KEYWORDS: LBOUND intrinsic, array assumed-size DEFECT TYPE: Erratum STATUS: Published QUESTION: The description of the value returned by LBOUND (ARRAY,DIM) does not appear to consider the case where ARRAY is an assumed-size array and DIM equals the rank of the array. Does the value returned for such a case really depend on whether the dimension DIM of ARRAY has size zero? ANSWER: No. The value returned is independent of the size of the dimension. Discussion: The text in the case (i) description of LBOUND does not include the information about the value returned for the situation where ARRAY is an assumed-size array and DIM equals the rank of the array. An edit is provided to correct that omission. EDIT: In section 13.13.52 replace the text of case (i) [214:22-25] with: "For an array section or for an array expression other than a whole array or array structure component, LBOUND(ARRAY,DIM) has the value 1. For a whole array or array structure component, LBOUND(ARRAY,DIM) has the value: (a) equal to the lower bound for subscript DIM of ARRAY if dimension DIM of ARRAY does not have extent zero or if ARRAY is an assumed-size array of rank DIM, or (b) 1 otherwise." SUBMITTED BY: Hideo Wada, Chair IPSJ/ITSCJ SC22/Fortran HISTORY: 93-036 m124 (4) submitted 93-096 m124 Draft response 93-146 m125 Revised response, approved unanimous consent 93-255r1 m127 ballot passed 23-1 93-324 m127 item 157 approved uc HOLD pending 157 94-034 m128 X3J3 ballot passed item 157 25-2 94-160 m129 WG5 ballot approved with edits requested 94-168 m129 requested edits as per WG5 ballot N977 m131 rewording of part (a) of edit and move 'otherwise'. N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 a scalar or 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 did not contain the following words at the end of the first paragraph of edit 2 "If such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent." The earlier answer also included different wording for the start of the second paragraph of edit 2: "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 3. "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." An earlier answer to this defect included the edit: 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." The earlier versions of edits 2 and 3, along with edit 1 and the just mentioned deleted edit were included in corrigendum 2. EDITS: 1. 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" 2. 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 such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent. If the dummy argument has the TARGET attribute and is either a scalar or 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." 3. 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 a scalar or 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 95-281 m135 revised edits after errors were discovered, WG5 approved (N1161) 96- m136 X3J3 ballot, approved 15-1, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000126 TITLE: Character Entry statements and Partial Association KEYWORDS: character, ENTRY statement, function, association - partial DEFECT TYPE: Erratum STATUS: Published QUESTION: In section 14.6.3.3 there is text that indicates that partial association can occur between character entities through the use of ENTRY statements. Is this correct? ANSWER: No, the statement is not correct. Discussion: The definition of "partially associated" appears in section 14.6.3.3: "Two scalar entities are partially associated if they are associated without being totally associated." Section 12.5.2.5 'ENTRY Statements' indicates the characteristics of the result of a function named on an ENTRY statement must be the same as the characteristics of the result of the function named on the FUNCTION statement when the type of the result is character. It also indicates the result variables identify the same variable. As the result variables identify the same variable they are not partially associated. An edit is provided to correct the standard in section 14.6.3.3. EDIT(S): In section 14.6.3.3 in the sentence (last two lines of page 248) [248:40-41] "For character entities, partial association may occur only through argument association, or the use of COMMON, EQUIVALENCE, or ENTRY statements." change "COMMON, EQUIVALENCE, or ENTRY" to "COMMON or EQUIVALENCE" SUBMITTED BY: Janice C. Shepherd 93-092 HISTORY: 92-051 Based on original response 93-006.49, 93-091 (jw note) 93-092 Response 93-147 m125 Revised response, approved unanimous consent 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000128 TITLE: Use associated generic names and renaming KEYWORDS: use association, generic name, use renaming DEFECT TYPE: Erratum STATUS: Published QUESTION: In section 11.3.2 the standard indicates that if two generic interfaces are accessible in the same scoping unit and have the same name they are interpreted as a single generic interface. How does the phrase 'the same name' apply when a generic identifier has been renamed on a USE statement? More specifically, given the following module definitions: MODULE M1 INTERFACE GEN1 SUBROUTINE S1 (I) END SUBROUTINE END INTERFACE END MODULE MODULE M2 INTERFACE GEN2 SUBROUTINE S2 (I,J) END SUBROUTINE END INTERFACE END MODULE MODULE M3 INTERFACE GEN1 SUBROUTINE S3 (I) END SUBROUTINE END INTERFACE END MODULE which of the following code fragments are standard conforming? a) USE M1, GEN => GEN1 USE M2, GEN => GEN2 b) USE M1 USE M2, GEN1 => GEN2 c) USE M1 USE M3, OTHERGEN => GEN1 ! Avoid conflict with GEN1 from M1 ANSWER: The local name of a generic interface accessed through use association is the name that is significant when determining if that generic interface has the same name as any other accessible generic interface. All three code fragments are standard conforming. Discussion: In section 14.1.2.3 rules for "Unambiguous generic procedure references" are provided. These rules "must be satisfied by every pair of specific procedures that have the same generic name". In code fragment a, the generic interface named "GEN" is interpreted as a single generic interface and subroutines S1 and S2 are specific names of that interface. The rules in 14.1.2.3 also are met. In code fragment b, because GEN2 is renamed as GEN1, it is GEN1 that is the local name of the generic interface accessed from module M2. The generic interface accessed from M1 also has local name GEN1, so the two generic interfaces are treated as a single generic interface, based on the 11.3.2 rules. In code fragment c, OTHERGEN is the local name for GEN1 accessed from module M3. GEN1 is the local name for GEN1 accessed from module M1. As these local names are not the same, the generic interfaces are not treated as a single generic interface. The sentence in section 11.3.2 that states that "If two or more generic interfaces that are accessible in a scoping unit have the same name" does not clearly state that the name is a "local" name which was the intent of the standard. An edit is provided to correct this. EDIT: The sentence in section 11.3.2 that states that if two "generic interfaces that are accessible in a scoping unit have the same name" [158:26-27], change "the same name" to "the same local name". SUBMITTED BY: Janice C. Shepherd HISTORY: 93-058 m124 Submitted 93-096 m124 Draft response 93-098 (jw note) 93-149 m125 Revised response, approved 17-1 93-255r1 m127 ballot passed 24-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=-3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character" The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,- 1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. Similar corrective edits are included for the definitions of constant and restricted expressions. EDITS: 1. In section 7.1.6.1, in the first list, in item 2 [77:20], change: "either constant expressions or implied-DO variables," to: "constant expressions," 2. In section 7.1.6.1, in the first list, in item 6 [77:28], delete the last "or" 3. In section 7.1.6.1, in the first list, add as item 7 and renumber the rest [77:28+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are constant expressions, or" 4. In section 7.1.6.1, in the second list, in item 2 [77:39], change: "either initialization expressions or implied-DO variables," to: "initialization expressions," 5. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 6. In section 7.1.6.1, in the second list, add as item 7 and renumber the rest [78:10+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are initialization expressions, or" 7. In section 7.1.6.2, in the list, in item 5 [79:4], change: "either restricted expressions or implied-DO variables," to: "restricted expressions," 8. In section 7.1.6.2, in the list, in item 9 [79:15], delete the last "or" 9. In section 7.1.6.2, in the list, add as item 10 and renumber the rest [79:15+]: "(10) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are restricted expressions, or" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-027 Submitted 93-088 Draft response approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. 94-221 m130 X3J3 ballot failed 22-1 94-244 m130 Edits revised. Approved u.c. 94-306 m131 X3J3 ballot, approved 19-0 95-044 m132 WG5 ballot, approved -------------------------------------------------------------------------------- NUMBER: 000130 TITLE: Multiple statements on line with END statement KEYWORDS: END statement, source form DEFECT TYPE: Erratum STATUS: Published QUESTION: Can the end statement of a program unit be followed on the same line with statements for another program unit? By use of a ';' one can have multiple statements appear on a single line as in: A = 1; B = A; The standard does not seem to indicate one way or another whether an END statement can be followed by another statement on the same line. Presumably the statement would belong to the next compilation unit if such use was allowed, e.g.: END; SUBROUTINE S It is hoped that the intent of the standard is that any statement appearing on the same line as a program unit END statement must appear before the END statement. Note that END; SUBROUTINE S looks very much like END SUBROUTINE S; with a slight typo. ANSWER: No, a program unit END statement cannot be followed on the same line with statements for another program unit. The text in 3.3 "Source Form" is incomplete and an edit is provided for its repair. EDIT: Replace the first sentence of 3.3 [21:33] with: A Fortran program unit is a sequence of one or more lines, organized as Fortran statements, comments, and INCLUDE lines. SUBMITTED BY: Janice C. Shepherd HISTORY: 93-059 Submitted 93-094 Approved response 93-111 m125 ballot approved 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000131 TITLE: Formatted Input and Kind Type Parameters KEYWORDS: kind type parameter, i/o list-directed, i/o format-directed, i/o namelist DEFECT TYPE: Erratum STATUS: Published QUESTION: The standard is unclear about the interaction of kind type parameters in formatted input records with formatted READ statements. Question 1: Which types of data, if any, can appear with kind type parameters in formatted input records with list-directed READ statements and non-list-directed formatted READ statements? Section 10.5.1.1 'Integer Editing' indicates that integer constants are valid input. As the definition of integer constant includes kind type parameters then one is to assume that valid input for integer editing includes integer constants listed with kind numbers. Section 10.5.1.2.1 'F editing' describes the exponent of a valid input field as ending with a signed integer constant, but there is no mention of a kind type parameter for a real constant. An integer constant can have a kind type parameter, but the kind type parameter is the kind type parameter for the integer constant not the real constant. Section 10.5.2 'Logical editing' indicates that the T or F in the input field can be followed by additional characters but gives no indication as to whether such characters might be a kind type parameter for the logical constant and that they should be recognized as a kind type parameter. Section 10.5.3 'Character editing' mentions that the characters transferred must have the same kind parameter as the data item, but is not clear as to whether the kind parameter can actually appear in the input field. Question 2: If kind type parameters are permitted in a formatted input field, does the field width 'w' specified in the corresponding edit descriptor include the characters that make up the kind type parameter? Question 3: If kind type parameters are permitted in a formatted input field, is it an error if the kind type parameter specified in the input field is not the same as the kind type parameter of the data item in the input list, for non-character data? ANSWER: 1) The standard should disallow kind type parameters in input data, but does not. This is an error that is corrected by the edits below. 2) Irrelevant. 3) Irrelevant. Discussion: This is an oversight in the standard, as a result of the relatively late addition of kind type parameters. REFERENCES: ISO/IEC 1539:1991(E), sections 10.5.1.1, 10.5.1.2.1, 10.5.2, 10.5.3, 10.8, 10.8.1, 10.8.2, 10.9, 10.9.1.3, 10.9.2.1 EDITS: 1. In Section 10.5.1.1, third paragraph [139:37-38], change "be in the form of an optionally signed integer constant" to "be a (R401)". note: is a BNF term. 2. In Section 10.5.1.1, fourth paragraph [139:45], change "in the form of an unsigned integer constant" to "as a ". Change "Note that an integer constant" to "Note that a ". note: This deals with output, not input, but we should make it clear that output doesn't produce kind type parameters either. 3. In Section 10.5.1.1, sixth paragraph [140:6], change "the unsigned integer constant" to "the ". 4. In Section 10.5.1.2.1 [140:25], list item (1), change "Explicitly signed integer constant" to "A followed by a ". 5. In Section 10.5.1.2.1 items (2) and (3) [140:26-27], change "an optionally signed integer constant" to "a ". 6. In Section 10.5.2, second paragraph [143:47], change "additional characters in the field" to "additional characters in the field, which are ignored". 7. In section 10.5.3, first paragraph [144:7-9], replace the last sentence with "The kind type parameter of all characters transferred and converted under control of one A or G edit descriptor is implied by the kind of the corresponding list item." 8. In Section 10.8, second paragraph [148:17], replace "constant with no kind type parameter specified." with "constant. Neither nor may have kind type parameters specified. The constant is interpreted as though it had the same kind type parameter as the corresponding list item." 9. In section 10.8.1, sixth paragraph [149:1-2], replace "character literal constant of the same kind as" with "possibly delimited sequence of zero or more s whose kind type parameter is implied by the kind of". 10. In section 10.8.2, ninth paragraph [151:7], delete "possibly are preceded by a and an underscore,". 11. In section 10.8.2, tenth paragraph [151:11], delete "possibly are preceded by a and an underscore,". 12. In Section 10.9, third paragraph [151:31-32], replace "constant with no kind type parameter specified." with "constant. Neither nor may have kind type parameters specified. The constant is interpreted as though it had the same kind type parameter as the corresponding list item." 13. In section 10.9.1.3, fifth paragraph [153:15-16], replace "character literal constant of the same kind as" with "delimited sequence of zero or more s whose kind type parameter is implied by the kind of". 14. In section 10.9.2.1, seventh paragraph [155:12], delete "possibly are preceded by a and an underscore,". 15. In section 10.9.2.1, eighth paragraph, [155:16], delete "possibly are preceded by a and an underscore,". SUBMITTED BY: Janice C. Shepherd (x3j3/93-116) HISTORY: 93-116 submitted 93-118r1 m125 Approved by unanimous consent 93-118r2 m125 Replaced response, approved by unanimous consent 93-255r1 m127 000098 subsumed 93-255r1 m127 ballot failed 23-1 93-302 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000132 TITLE: SYSTEM_CLOCK intrinsic conformance requirements KEYWORDS: SYSTEM_CLOCK intrinsic DEFECT TYPE: Erratum STATUS: Published QUESTION: Does a Fortran language processor conform to the standard if it treats the intrinsic SYSTEM_CLOCK in any of the following ways? 1. Increment COUNT by 1 every .05495 seconds (18.2 times per second), but return a COUNT_RATE of 18. For this case, accuracy would be lost in the following code example: PROGRAM EXAMPLE INTEGER :: TSTART, TSTOP, RATE REAL :: TDIFF CALL SYSTEM_CLOCK (COUNT=TSTART, COUNT_RATE=RATE) CALL USERS_PROCESS_TO_BE_TIMED () CALL SYSTEM_CLOCK (COUNT=TSTOP) TDIFF = (TSTOP - TSTART) / RATE PRINT *, TDIFF, "SECONDS" ! this number has an error > 1% END 2. Increment COUNT by 10 every .05495 seconds (COUNT incremented by a total of 182 each second), and return a COUNT_RATE of 182. 3. Increment COUNT by a variable amount every .05495 seconds, and return a COUNT_RATE of 100. ANSWER: 1. Yes, this is conforming. 2. Yes, this is conforming. 3. Yes, this is conforming. Discussion: The standard states that for a system with a clock present, the processor-dependent value COUNT (13.13.104) is incremented by one for each clock count (whatever the processor defines that to be), and that COUNT_RATE is some number of processor clock counts per second. The standard does not suggest that the value returned for COUNT by one call to SYSTEM_CLOCK be "numerically one greater" than the value of COUNT from the previous call to SYSTEM_CLOCK but only that COUNT increases in some predictable manner. An edit is provided to clarify that COUNT_RATE is a processor-dependent approximation. A standard conforming processor is free to return any of its values at some time other than when COUNT increases by one. It is permissible for a processor to increment COUNT by one on every clock cycle internally, but make the return arguments for SYSTEM_CLOCK available to the user at a time granularity no finer than every 10 COUNTS for instance should it choose to do so. Note that it is even possible that the duration of one clock tick be longer or shorter than another. In this case COUNT_RATE could be the average value required to convert internal time to seconds. It should also be noted that the system clock (SYSTEM_CLOCK) and the real time clock (DATE_AND_TIME) need not be tied together. An implementation that employed "processor ticks" for the former and a phone call to an atomic clock for the latter would be standard conforming. EDIT: In section 13.13.104, SYSTEM_CLOCK, change the text for COUNT_RATE from 'the number' to 'a processor-dependent approximation to the number' [236:11] SUBMITTED BY: T. Lahey HISTORY: 93-130 m124 submitted 93-182 m125 Draft response 93-212 m126 Revised response passed (11-2) 93-255r1 m127 ballot failed 22-2 93-312 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000133 TITLE: Definition of "token" as used in section 3.3.1 KEYWORDS: token, source form - free, blanks DEFECT TYPE: Interpretation STATUS: Published QUESTION: What constitutes a token for purposes of complying with the rules for blanks in section 3.3.1 "Free source form"? Specifically, are blanks permitted on either side of the underscore in a literal constant with a kind parameter (whether or )? If the kind parameter is a name, then surely the name is a token itself and cannot be part of a literal constant token. So if a literal constant with a kind parameter is two separate tokens, can't there be blanks in there somewhere? Related question: Are blanks permitted on either side of the exponent letter in a real literal constant? ANSWER: No, in free source form, blanks are not permitted on either side of an underscore that separates a literal constant from its kind type parameter, nor are they permitted on either side of an . Discussion: Section 3.3.1 describes the general rules of free source form. The general rules for the formation of tokens, which apply to both source forms, are given in 3.2. Section 3.2 states Lexical tokens are sequences of characters with indivisible interpretations that constitute the building blocks of a program. and gives examples of lexical tokens including: ... keywords, names, literal constants other than complex literal constants, operators, labels, ... Section 3.3.1 allows blanks to occur between the tokens of a complex literal constant but blanks are not allowed within any other literal constant form because such other literal constants are, by 3.2, (indivisible) lexical tokens. EDITS: None. SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-131r1 m125 Submitted 93-219 m126 Draft response, approved uc 93-255r1 m127 ballot passed 23-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000134 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDITS: SUBMITTED BY: Dick Weaver HISTORY: 93-155 m125 submitted 93-215r2 m126 Proposed response, adopted uc 93-255r1 m127 ballot failed 22-2 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000135 TITLE: INTENT(IN) conformance KEYWORDS: INTENT(IN) attribute, conformance DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 1.4, Conformance, states "An executable program (2.2.1) is a standard-conforming program if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this International Standard." Consider the following fragment: SUBROUTINE A (X) INTENT(IN) :: X IF (expr) X = 1.0 The intent attribute (5.1.2.3) specifies that X must not be redefined or become undefined during the execution of the procedure. Does the use of X in this fragment meet both conformance requirements -- using only those forms and relationships described herein -- the executable program has an interpretation (assume that "expr" is false) according to this International Standard? If "yes", was it the intent of the standard that a conforming processor not reject this program until X=1.0 is executed? ANSWER: No, the use of X in this fragment does not meet the conformance requirements of using only forms and relationships described in the standard. However, the existing wording of the standard could be interpreted to imply that the fragment was conforming if "expr" were always false. The edits below clarify that the fragment is non-conforming whether or not "X=1.0" is executed, and apply equally to the INTENT attribute in a type declaration statement and the INTENT statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.1 and 14.7.5 EDITS: 1. Section 5.1.2.3 following R511 - add the following constraint after the existing constraint [44:24+]: "Constraint: A dummy argument with the INTENT(IN) attribute, or subobject of such a dummy argument, must not appear (1) As the of an , (2) As a DO variable or implied-DO variable, (3) As an in a , (4) As a in a if the appears in a NML= specifier in a , (5) As an in a , (6) As an IOSTAT= or a SIZE= specifier in an input/output statement, (7) As an inquiry specifier variable in an INQUIRE statement, (8) As a in an or , (9) As an actual argument in a reference to a procedure with an explicit interface when the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute, or <<(10) In an .>>" SUBMITTED BY: Dick Weaver HISTORY: 93-156 m125 initial submission 93-191 m126 proposed response 93-208 m126 revised response, approved uc 93-255r1 m127 ballot failed 21-3 93-326 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-091 m128 additional edit supplied, approved 16-1 94-116 m129 X3J3 ballot failed 10-13 94-274r1 m130 Revised response, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot, approved, with edits -------------------------------------------------------------------------------- NUMBER: 000136 TITLE: scalar-structure-component in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: Published QUESTION: R536 states that a can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A%B, I = 1,1) is conforming while (A%B, I = 1,2) is not conforming Is there a constraint missing, along the lines of must have at least one with a ANSWER: Yes. This is an oversight that is corrected with the edit specified below. Discussion: The DATA implied-DO is intended to be used as an iterative mechanism to initialize part or all of an array. The BNF metaterm must be included in R536 to allow an array of structures to be initialized. Note that the BNF metaterm (R615) defines the term "array element" to apply to a designator only when a subscript list is present on the rightmost of the . Therefore, A%B(10) is an array element designator but A(10)%B is a scalar structure component designator (assuming B is scalar). Since the DATA implied-DO is intended to be used with arrays, allowing a form such as DATA (A%B, I = 1, 1) ... was not intended and provides no useful language functionality. EDIT: In section 5.2.9, following the second constraint [52:20], insert the following constraint: Constraint: The must contain at least one that contains a . SUBMITTED BY: Dick Weaver HISTORY: 93-157 m125 submitted 94-045r1 m128 proposed response, approved 10-3 94-116 m129 X3J3 ballot approved 20-3 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: R536 states that an can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A(2), I = 1,1) is conforming while (A(2), I = 1,2) is not conforming Is there a constraint missing, along the lines of s and s that are s must each have at least one subscript whose value is a function of the . ANSWER: No. There is no constraint missing. Discussion: The first implied-DO was standard conforming in FORTRAN 77, and continues to be in Fortran 90. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 94-291 m130 alternate response, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: Published QUESTION: 4.4.1 "Derived Type Definition", fourth paragraph following the five constraints following R429 states If a type definition is private ... any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. 5.2.3 "Accessibility Statements", third constraint, states A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility ... Noting that "accessible only within the module" is the definition of PRIVATE accessibility, it seems that the constraint requires the user to do something (specify the PRIVATE attribute) that is already specified as done per 4.4.1. Is the user required to specify PRIVATE accessibility for a module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility? ANSWER: Yes. The text in 4.4.1 is a general statement of the requirement. The text in 5.2.3 is a specific statement of the requirement. EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 93-159 m125 submitted 94-208r1 m129 response; approved u.c. 94-221 m130 X3J3 ballot, approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 5.1.2.11 "INTRINSIC attribute" states The INTRINSIC attribute specifies that an object name in a declaration containing this attribute must be the specific or generic name of an intrinsic function... Section 5.1.2.10 "EXTERNAL attribute" has similar wording Question 1: Given REAL, INTRINSIC :: SIN REAL, EXTERNAL :: ABC Are SIN and ABC object names? If so, of what objects? Question 2: Given LOGICAL, INTRINSIC :: SIN What entity is being declared with the type 'LOGICAL'? ANSWER: Answer 1: SIN and ABC are not object names. The standard should not have used 'object name' in sections 5.1.2.10 and 5.1.2.11, but the name of the appropriate syntactic class. The edits below correct these sections. Answer 2: No entity is being declared with the type LOGICAL. Specifying a data type for a generic intrinsic function does not, in itself, remove the generic property from that function (section 5.1, [40:36-38]). There is no requirement for the data type specified in such a case to be one of the return types of the generic intrinsic. REFERENCES: 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'an object name' with 'a function name' [48:26] 2. Section 5.1.2.11 Replace 'an object name' with 'a function name' [48:30] SUBMITTED BY: Dick Weaver X3J3/93-160 HISTORY: 93-160 m125 Submitted 93-183 m125 response withdrawn 93-314r1 m127 response withdrawn 94-209 m129 minor changes to response, failed 9-10 Current version is 93-314r1. 3rd and 4th edits should be dropped. 94-292 m130 reversed answer 2 and reduced to 2 edits; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: Published QUESTION 1: Can a namelist group item be of derived type if the components of the derived type are inaccessible? Section 5.4 indicates that a namelist-group-name cannot have the PUBLIC attribute if any of its items have the PRIVATE attribute. An object of derived type can have the PUBLIC attribute even if its components are private, so this text is insufficient. While Section 9.4.2 indicates that an input/output list item can not be of derived type if any of its components are not accessible, this section does not cover namelist list items. Here is an example of variables of derived type with private components appearing in namelist lists: Example 1: MODULE M TYPE T PRIVATE INTEGER I,J END TYPE TYPE (T) X NAMELIST /N1/ X END MODULE PROGRAM NN USE M TYPE (T) NX NAMELIST /N2/ NX END PROGRAM QUESTION 2: If a namelist group name or a namelist group item is accessed via use association and the USE statement supplies a rename of the group name or of the item, is it the original name that appears in the input/output record or the name introduced through renaming? Section 10.9.1 item (2) appears to indicate that for the group name it is that name that appears in the input statement that is used. Other references in sections of 10.9 do not appear to contain further details of which name to use. As renaming on USE statements is provided to limit name conflicts within the scope that has the USE statement, it appears that such renaming should not affect the names used in namelist I/O. Here is an example to consider: Example 2: MODULE M NAMELIST /N/ I, J INTEGER K END MODULE SUBROUTINE S() USE M , NN => N, JJ => J, KK => K CHARACTER J, K NAMELIST /X/ KK, K I = 1 JJ = 2 KK = 3 J = 'A' K = 'B' WRITE(10, NML=NN) WRITE(10, NML=X) END ANSWERS: 1. No. As with an input/output list, the components of any namelist group objects referenced in a namelist input/output statement which are of derived type must be accessible. An edit to clarify this is included. 2. Section 10.9.1 item (2), should indicate that the namelist group name used in the namelist input/output record is the namelist group name specified in the original NAMELIST statement. This would be consistent with sections 10.9.1 and 10.9.2.2 which both state that the name used in the name value sequence is the name of the item from the NAMELIST statement. In particular, the output of the supplied example (assuming that the DELIM= specifier has been assigned the value APOSTROPHE) is: &N I=1, J=2 / &X KK=3, K='B'/ An edit is provided to correct section 10.9.1 EDITS: 1. In section 5.4, add to the end of the second constraint [56:13] "or have private components" 2. In section 10.9.1, replace item (2) with [151:39-40] "The character & followed immediately by the as specified in the NAMELIST statement," SUBMITTED BY: Janice C. Shepherd HISTORY: 93-189 submitted 93-218 m126 proposed response approved 13-1 93-255r1 m127 ballot failed 21-3 93-299r1 m127 withdrawn 94-067 m128 clarified answer 2 and added new edit. Approved uc, but then returned to status "X3J3 consideration" as meeting 127 ballot not completely addressed. 94-178 m129 altered first edit, approved u.c. 94-221 m130 X3J3 ballot approved u.c.; accept Martin edit N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure, external procedure DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: In Fortran programs it is sometimes the way an entity is referenced that partially determines what the entity is. For example given the following specification section: INTEGER X it is not clear until X is referenced as to whether X is the name of a function or the name of a variable. If such a specification statement appears in the scope of a module, can a reference to the entity by use association partially determine what the entity is? Section 11.3.2 indicates that the local name of an entity made accessible by use association may appear in no other specification that would cause any attribute of the entity to be respecified in the scoping unit (except the local name can appear in a PUBLIC or PRIVATE statement if the scoping unit is a module). But this section does not comment on the following example: MODULE M1 IMPLICIT INTEGER(A) INTEGER UNCLEAR1, UNCLEAR2 EXTERNAL ALSO_UNCLEAR ! Could be a subroutine or a function INTEGER SIN ! Could be a variable or an intrinsic CONTAINS SUBROUTINE XX(I) I = UNCLEAR1() ! Indicates UNCLEAR1 ! is a function not a variable. END SUBROUTINE END MODULE USE M1 WRITE(6,*) UNCLEAR1(), UNCLEAR2(), ALSO_UNCLEAR() END ANSWER: No. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider the classification of a procedure as a function or a subroutine as this can be specified by executable statements. It was the intent that attributes of all use associated entities and the classification of use associated procedures be specified within the scope of the module. An exception was made for the PUBLIC and PRIVATE attributes. An edit is provided to clarify the intent. EDIT: In section 11.3.2, ahead of "Examples:" add 2 new paragraphs [158:41+]: "A procedure with an implicit interface and public accessibility must explicitly be given the EXTERNAL attribute in the scoping unit of the module; if it is a function, its type and type parameters must be explicitly declared in a type declaration statement in that scoping unit. An intrinsic procedure with public accessibility must explicitly be given the INTRINSIC attribute in the scoping unit of the module or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 94-242r1 m130 revised text and edit; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot approved, with Reid edit -------------------------------------------------------------------------------- NUMBER: 000144 TITLE: Specification expressions and implicit typing. KEYWORDS: expression - specification, implicit typing, host association DEFECT TYPE: Interpretation STATUS: Published QUESTION: Section 7.1.6.2 indicates: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit typing rules currently in effect for the scoping unit, or by host or use association. In the following code fragment, it is the appearance of the name XX in the COMMON statement that makes the entity XX of the host inaccessible. Is the use of XX in the specification expression valid, even though it occurs before the COMMON statement? INTEGER XX ... CONTAINS SUBROUTINE INNER() IMPLICIT INTEGER(X) CHARACTER*(XX) CHARAUTO COMMON /C/ XX ... Section 12.1.2.2.1 indicates that if a host entity is inaccessible only because a local entity of that name is initialized in a DATA statement, the local entity must not be referenced or defined prior to the DATA statement. A similar statement prohibiting a reference to XX prior to its declaration in the COMMON statement does not appear to exist. ANSWER: Yes. Discussion: Although the concepts may appear to be similar, DATA statements may occur throughout the executable statements while COMMON statements may not. The difference noted is deliberate. A suggestion to remove the restriction on the DATA statement would be appropriate for a future revision of the Fortran standard. EDIT: None SUBMITTED BY: Janice C. Shepherd HISTORY: 93-192 m126 submitted 93-236 m126 response, approved uc 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Intrinsic Type Names KEYWORDS: conformance, intrinsic type, derived type, names - class DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 QUESTION: Consider the following program: PROGRAM EX1 INTERFACE SQRT REAL FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC SQRT WRITE(*,*) SQRT(16) END SUBROUTINE TEST END According to the standard (section 14.1.2.4) the name SQRT is both generic in TEST (since it is a generic intrinsic) and in the host scope EX1 since it is a generic user procedure. According to 14.1.2.4.1 the reference to SQRT(16) should resolve to USERSQRT; i.e. even though the user specifies intrinsic for SQRT the user ends up with a reference to a user procedure. Contrast that with the following example where SQRT has been replaced by CSQRT: PROGRAM EX2 INTERFACE CSQRT COMPLEX FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC CSQRT WRITE(*,*) CSQRT(16) END SUBROUTINE TEST END In this case CSQRT is the name of a specific intrinsic procedure and the reference CSQRT(16), is according to 14.1.2.4.2 to that procedure, which since the argument type is integer, is invalid. By changing from a generic to a specific intrinsic name, the call resolution changes drastically which a user could find very confusing - it seems that the INTRINSIC attribute confers different properties in the two cases. Is this interpretation of the standard correct? If so, was this the intended behavior? ANSWER: Yes, the interpretation of the standard is correct. Yes, it was the intended behavior. Discussion: In the first example, SQRT is established to be a generic name. The resolution of a reference to a generic name is specified in 14.1.2.4. In the second example, CSQRT is established to be a specific intrinsic name within the internal procedure. In a reference to a specific intrinsic, any arguments specified must match those expected by the specific intrinsic. EDITS: None. SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted 94-294 m130 response approved u.c. 94-306 m131 X3J3 ballot approved 19-0 95-044 m132 WG5 ballot approved, with Shepherd edit -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (page 228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor-dependent value be set into the seed on all such calls to RANDOM_SEED with no actual argument? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) No, it is not the intent of the standard that X must equal Y after the the example calls to RANDOM_SEED and RANDOM_NUMBER. The standard states: If no argument is present, the processor sets the seed to a processor dependent value. in 13.13.84. This leaves the value of the seed and the method of generating that value up to the processor. Therefore, the answer to the second question is no, it is not the intent of the standard that the same processor-dependent value be set into the seed on all such calls to RANDOM_SEED with no actual argument. (2) Yes. It is the intent of the standard that X2 equals X3 after the last call to RANDOM_NUMBER in the example. An edit is supplied to clarify that this is the intent. Note that the program fragment in question 2 is standard conforming for a given processor only if that processor returns the value '2' or '1' in the SIZE argument when RANDOM_SEED is called. EDIT: In section 13.13.84 add the following text [228:13+] "The pseudorandom number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Computation of the seed from argument PUT is performed in a processor dependent manner. The value specified by PUT need not be the same as the value returned by GET in an immediately subsequent reference to RANDOM_SEED. For example, following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. When the values differ, the use of either value as the PUT argument in a subsequent call to RANDOM_SEED will result in the same sequence of pseudorandom numbers being generated. For example, after execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot failed 13-7 95-142r1 m133 revised response, approved 10-2 95-183 m134 X3J3 ballot failed 12-5 95-281 m135 revised edit, approved by WG5 (N1161) 96- m136 X3J3 ballot, approved 15-1, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function, primary DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 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 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000150 TITLE: Undefinition of implied-DO variables in I/O statements KEYWORDS: i/o statement, implied-DO variable, defined, definition, undefined DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 9.4.3 (in two places) states that when a condition such as an error condition, an end-of-file condition, or an end-of-record condition occurs, execution of the I/O statement terminates and "any implied-DO variables become undefined". Section 14.7.6, item (6) states that when any of these conditions occur, "some or all of the implied-DO variables may become undefined" and references 9.4.3. It appears the intent of the standard was that all implied-DO variables in an I/O statement in which such a condition occurs become undefined. Is that the intent of the standard? ANSWER: Yes. An edit is supplied to make the wording express this intent in both sections 9.4.3 and 14.7.6. Discussion: In several of the draft versions of Fortran 90, specifiers appeared in various I/O statements with values that depended on knowing exactly how an I/O list had been processed prior to the occurrence of an error condition. Late in the development of the standard, the committee realized that no value can be relied upon when an error occurs, and no assumptions can be made about how the I/O list has been processed. Such specifiers were removed but some related text was apparently overlooked. The standard can make no assumptions about how an implementation will process an I/O statement so it can not make any assumptions about which implied-DO variables could conceivably be still defined. Consider the following READ statement: READ *, (A(I), I = 1, 5), (B(J), J = 1, 5) If J was defined prior to the READ statement and if one of the cited conditions occurred while the first implied-DO was "active", the standard could not make the assumption that J remained defined because it could be impossible for the program or I/O system to determine that it was the first implied-DO that was active. EDITS: 1. Section 9.4.3, second paragraph following the numbered list [124:44], change any implied-DO variables become undefined to if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 2. Section 9.4.3, second-to-last paragraph [125:7-8], change any implied-DO variables become undefined to if the input statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined 3. Section 14.7.6, item (6) [251:43-45], change input/output statement, some or all of the implied-DO variables may become to input/output statement and the statement contains any implied-DOs, all of the implied-DO variables in the statement become SUBMITTED BY: Larry Rolison HISTORY: 93-243 m127 submitted 93-300 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000151 TITLE: Defined Operators with POINTER Operands KEYWORDS: defined operator, pointer DEFECT TYPE: Interpretation STATUS: Published QUESTION: Is it the intent of the standard that operators with pointer operands are disallowed or is this an oversight that requires correction? Consider the program below. Here a user has tried to define an operator .in. that returns true if a value is found in a tree and false if not. Unfortunately one of the arguments to LISTMEMBER is a pointer. This is rejected by the compiler because according to the standard, section 12.3.2.1.1 [169:17-18], the dummy arguments must have intent IN but pointers must not have this intent, section 5.2.1 [49:3]. It appears then that an operator with pointer operands is not allowed in Fortran-90. MODULE LIST TYPE NODE INTEGER VALUE TYPE (NODE), POINTER :: NEXT END TYPE NODE INTERFACE OPERATOR (.IN.) ! check for membership in tree MODULE PROCEDURE LISTMEMBER END INTERFACE CONTAINS ! -------------------- IS A MEMBER ? -------------------- FUNCTION LISTMEMBER(VALUE,ROOTNODE) ! If ROOTNODE is given INTENT (in) then the compiler complains that ! intent may not be given to a variable with the POINTER attribute. ! If INTENT(IN) is not ! given then the compiler complains that the dummy argument rootnode must ! have an intent (when compiling the interface definition for .IN. above). TYPE (NODE), POINTER :: ROOTNODE TYPE (NODE), POINTER :: N INTEGER, INTENT(IN) :: VALUE LOGICAL LISTMEMBER LISTMEMBER = .FALSE. N => ROOTNODE DO WHILE(ASSOCIATED(N)) IF( N%VALUE == VALUE ) THEN LISTMEMBER = .TRUE. EXIT ELSE N => N%NEXT END IF END DO END FUNCTION LISTMEMBER END MODULE LIST ANSWER: Fortran 90 does not allow defined operators with pointer operands. Dummy arguments to a defined operator must have the INTENT(IN) attribute, but pointers are not allowed to have this attribute (5.2.1, 12.3.2.1.1). EDIT: None. SUBMITTED BY: Graham Barber HISTORY: 93-247 m127 submitted 93-315 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000152 TITLE: Processor dependent values for list and namelist directed output KEYWORDS: i/o list-directed, i/o namelist DEFECT TYPE: Interpretation STATUS: Published QUESTION: In Fortran 90, section 10.8.2 [150:36-37], it states For numeric output, reasonable processor-dependent integer values of w, d, and e, are used for each of the numeric constants output The previous paragraph in the section discusses the choice of 0PFw.d or 1PEw.dEe edit descriptors based on d1 and d2 processor dependent integers. This would seem to suggest that d1 and d2 are chosen once and then used for all output values. Namelist formatting, section 10.9.2.1 [154:35-40], has similar text. Question: are w, d, e, d1, and d2 chosen once and then used for all values or can different values be chosen for each numeric constant? For each numeric constant kind? If the answer is "once", then a tabular presentation results, as in the following example for a sequence of integers. 1 234 56 789 3 1000 If the answer is "chosen for each constant" then a more efficient, compact, presentation could result. 1 234 56 789 3 1000 ANSWER: All of the selection methods described in the question above are allowed. The processor is free to choose the values for w, d, e, d1, and d2 based on the value or kind of the value being printed. The processor is also free to choose permanent (fixed) values for w, d, e, d1, and d2. EDIT: None. SUBMITTED BY: Dick Weaver HISTORY: 93-248 m127 submitted 93-301 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000153 TITLE: Defined Operations, dummy arguments INTENT(IN) KEYWORDS: INTENT(IN) attribute, defined operator DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 12.3.2.1.1 states If OPERATOR is specified in a generic specification, all of the procedures specified in the interface block must be functions that may be referenced as defined operations ..... The dummy arguments must be nonoptional dummy data objects and must be specified with INTENT(IN) .... In section C.11.4, "Example of a Module", "OPERATOR" is specified for interface blocks that specify the following procedures: ELEMENT, SUBSET, UNION, DIFFERENCE, INTERSECTION Looking at those procedures, is the example correct? ANSWER: The INTENT(IN) attribute must be explicitly specified in an operator function for each dummy argument; the attribute is not "implied". Thus, the example is incorrect. Edits are provided to correct the example. REFERENCES: ISO/IEC 1539:1991 (E) Sections 12.3.2.1.1 and C.11.4. EDITS: 1. Section C.11.4, in function ELEMENT [286:16,17], change INTEGER X to INTEGER, INTENT(IN) :: X and change TYPE (SET) A to TYPE (SET), INTENT(IN) :: A 2. Section C.11.4, in function UNION [286:21], change TYPE (SET) A, B, UNION to TYPE (SET) UNION TYPE (SET), INTENT(IN) :: A, B 3. Section C.11.4, in function DIFFERENCE [286:37], change TYPE (SET) A, B, DIFFERENCE to TYPE (SET) DIFFERENCE TYPE (SET), INTENT(IN) :: A, B 4. Section C.11.4, in function INTERSECTION [287:2], change TYPE (SET) A, B, INTERSECTION to TYPE (SET) INTERSECTION TYPE (SET), INTENT(IN) :: A, B 5. Section C.11.4, in function SUBSET [287:6], change TYPE (SET) A, B to TYPE (SET), INTENT(IN) :: A, B SUBMITTED BY: Dick Weaver HISTORY: 93-262 m127 submitted 93-325 m127 response approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot approved with Moss/Reid edit 94-179 m129 edit as per WG5 ballot N981 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000154 TITLE: EQUIVALENCE and zero-sized sequences KEYWORDS: EQUIVALENCE statement, zero-sized sequences DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 5.5.1 and its subsections discuss equivalence association and zero-sized sequences, but not in detail sufficient to answer the following questions: Given the following CHARACTER (LEN=4) :: A, B, C Question 1: are the following equivalence statements valid? COMMON /X/ A COMMON /Y/ B EQUIVALENCE (A, C(10:9)), (B, C(10:9)) ! the same zero-sized object is ! equivalenced to two different ! common blocks. EQUIVALENCE (A, C(10:9)), (B, C(100:90)) ! two different zero-sized objects ! are equivalenced to two different ! common blocks Question 2: is the following equivalence valid EQUIVALENCE (C, C(10:9)) Question 3: Is the following valid? EQUIVALENCE (C(10:9), C(100:90)) Question 4: It is generally the case that given CHARACTER (LEN=4) :: D, E, F then EQUIVALENCE (D, E) EQUIVALENCE (F, E) and EQUIVALENCE (D, E, F) both specify that D is equivalenced to F. Do the following specify the same storage associations? EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(2:1)) and EQUIVALENCE (D, E(2:1), F) EQUIVALENCE (D, E(2:1)) ! E(2:1) is zero sized EQUIVALENCE (F, E(3:1)) ! E(3:1) is also zero-sized and EQUIVALENCE (D, E(2:1), F) Question 5: is E(2:1) a subobject of E? ANSWER 1: Both equivalence statements are invalid. Introducing complex semantics to explain the meaning of equivalencing zero-length substrings with each other or with other variables adds little useful functionality to the language. Such equivalences should have been prohibited. An edit is included to make the prohibition. ANSWER 2: No. ANSWER 3: No. ANSWER 4: No. ANSWER 5: Yes. EDIT: In section 5.5.1, add a new constraint after the existing constraints [57:17+] "Constraint: A must not have length zero." SUBMITTED BY: Dick Weaver HISTORY: 93-264 m127 submitted 93-323 m127 response approved 14-5 94-034 m128 X3J3 ballot failed 10-18 95-281 m135 revise response, WG5 approved (N1161) 96- m136 X3J3 ballot approved 16-0, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000155 TITLE: Multiple USE statements, rename and only lists. KEYWORDS: USE statement, use renaming, ONLY DEFECT TYPE: Erratum STATUS: WG5 approved; ready for SC22 QUESTION: Section 11.3.2 states: (with some formatting to better show logic, tags added to assist references): R1109 is or [ =>] Constraint: Each must be a public entity in the module. Constraint: Each must be the name of a public entity in the module. ...... More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, (a) all public entities in the module are accessible and (b) the s and s are interpreted as a single concatenated . Questions: 1. Is the syntax ambiguous? Note: R1107 is USE [,] or USE , ONLY: [] R1109 is or [ =>] R522 is or Thus in an can parse either as R1109 or R1109 -> R522 . 2. Can s and s be concatenated as a as specified in (b)? s permit "", while rename lists require " => ". ANSWER: 1. Yes. The syntax is ambiguous ("" should be changed to ""). However removal of the ambiguity will be deferred to the next revision of the standard (Fortran 95). 2. No. The syntax is such that it might appear only the renames from s are being concatenated into the single . An edit is supplied to make it clear that all items from any contribute to the list of accessible local names and accessible s. Discussion: There are many other places in the standard besides R1109 where the same interpretation can be reached by more than one path through the syntax (e.g., could be removed from R533 since it is a special case of a ). Rather than fix this one ambiguity now, it will be deferred to the more general clean up in Fortran 95. Note that in Fortran 95 the appropriate edits to remove the ambiguity in R1109 are : 1. In section 11.3.2, R1109 [158:11] change "" to "" 2. In section 11.3.2, the first constraint following R1109 [158:13] change "" to "" 3. In section 11.3.2, paragraph beginning "A USE statement" [158:19] change "s" to "s" EDITS: 1. In section 11.3.2, in the first sentence after the constraints [158:16] change "the local name is the " to "the local name of a named entity is the " 2. In section 11.3.2, in the 2nd sentence of the 4th paragraph after the constraints [158:21-23] change " and the s and s are interpreted as a single concatenated " to ", the s and renames in s are interpreted as a single concatenated , and entities in the remaining items are accessible by those s or s (they may also be accessible by one or more renames)" SUBMITTED BY: Dick Weaver HISTORY: 93-265 m127 submitted 93-305 m127 response approved uc 94-034 m128 X3J3 ballot passed 26-1 94-160 m129 failed WG5 ballot 94-352 m131 revised response, approved u.c. 95-034r1 m132 X3J3 ballot failed 19-1 95-281 m135 revised response and edits, WG5 approved. 96- m136 X3J3 ballot approved 16-0, retains WG5 approval -------------------------------------------------------------------------------- NUMBER: 000156 TITLE: Forward references to a derived type definition KEYWORDS: pointer, derived type, forward reference DEFECT TYPE: Interpretation STATUS: Published QUESTION: Consider the following declarations involving a reference to a derived type: Case 1: A structure declaration makes reference to a derived type definition. TYPE(DEF) :: S TYPE DEF INTEGER I, J END TYPE Case 2: A derived type definition makes reference to another derived type definition. TYPE ONE TYPE(TWO) SUBSTRUCTURE END TYPE TYPE TWO INTEGER K END TYPE Case 3: A pointer is declared to be of derived type. TYPE(THING), POINTER :: FINGER TYPE THING REAL SKIN, HAND END TYPE Case 4: A pointer component is declared to be of derived type other than the derived type of which it is a component. TYPE ONE TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO INTEGER I, J END TYPE Case 5: Two pointer components are declared to be of derived types other than the derived type of which they are a component and each pointer is of the other derived type, thus tightly linking the two derived types. TYPE ONE INTEGER :: INT_FIELD TYPE(TWO), POINTER :: LINK END TYPE TYPE TWO REAL :: REAL_FIELD TYPE(ONE), POINTER :: LINK END TYPE Notice that in all of these cases, the initial derived type reference is a forward reference to the derived type's definition. For example, in Case 1, the definition of DEF follows its reference in the declaration of structure S. It seems that all of these declaration forms are prohibited by the standard because they involve forward references to derived type definitions. The relevant text is: Case 1: p. 43, lines 21-23 When a data entity is specified to be of a derived type, the derived type must have been defined previously in the scoping unit or be accessible there by use or host association. Case 2: p. 33, lines 22-23 Constraint: If the POINTER attribute is not specified for a component, a in the must specify an intrinsic type or a previously defined derived type. Case 3: Same as Case 1. Case 4: p. 33, lines 24-26 If the POINTER attribute is specified for a component, a in the must specify an intrinsic type or any accessible derived type including the type being defined. Case 5: Same as Case 4. However, the use of the word "accessible" in the paragraph cited from page 33 seems to be inexact. It could be construed to (a) be a shorthand way of saying "accessible by use association or host association" so the sentence would properly read ... or any derived type accessible by use association or host association including ... or (b) mean "available anywhere in the current scoping unit" so the sentence would properly read ... or any derived type defined in the current scoping unit or accessible by use association or host association, including ... The first case would mean that none of the cited forward reference forms are standard conforming. The second case would mean that the reference to a derived type from a pointer component of a structure (and only this case) could be a forward reference to another derived type. Did the standard intend to allow a forward reference to a derived type definition in none of the above declaration forms, in some of the above forms (which ones?), or in all of the above forms? ANSWER: Of the declaration forms shown above, the standard allows a forward reference to a derived type only in forms exemplified by Case 4 and 5. Discussion: The second supposition above about the meaning of the word "accessible" in the sentence cited from page 33 is the correct one. Note that in all declaration forms shown except Case 5, the forward reference can be removed by moving the derived type definition to precede the reference to it. Case 5 demonstrates a declaration form where the two derived types are tightly linked via the two pointers. Forward referencing can not be avoided in this form. This form and the forward referencing that goes with it needs to be allowed since a number of applications use linked list forms where a "parent" node points to a "child" and each "child" node points back at the "parent" node. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-269 m127 submitted 94-048r2 m128 proposed response, approved uc 94-116r1 m129 X3J3 ballot approved 22-1 N984 m131 WG5 approved -------------------------------------------------------------------------------- NUMBER: 000157 TITLE: LBOUND and UBOUND return values KEYWORDS: LBOUND intrinsic, UBOUND intrinsic, zero-sized dimension, return value DEFECT TYPE: Interpretation STATUS: Published QUESTION: The LBOUND intrinsic function returns the value 1 for a zero-sized dimension of an array and the UBOUND intrinsic function returns the value 0 for a zero-sized dimension of an array. X3J3 has stated a number of times in responses to public comments and in other public forums that zero-sized arrays were specifically designed into the language with all the rights and privileges of nonzero-sized arrays; that is, zero-sized arrays were not supposed to be treated like "second-class citizens". Given this informal approach and the formal way in which zero-sized arrays have been integrated into the language (see Chapters 6 and 7), it seems counter-intuitive for the LBOUND and UBOUND intrinsics to special-case zero-sized dimensions. For example, if a user declares an array as INTEGER array(10:3) the value 1 returned by LBOUND is no more meaningful than the value 10 that the user specified. In order for a program to know at run time whether or not an array or a dimension of an array has zero size, the program must still compare the lower bound to the upper bound or, better yet, use the SIZE intrinsic. Note that the same holds true for bounds that are calculated, like in ALLOCATE statements; that is, LBOUND should return the calculated value in these cases. The current descriptions of LBOUND and UBOUND seem to be incorrect with respect to zero-sized dimensions. Questions: (1) Are the descriptions of LBOUND and UBOUND, in fact, defective with respect to zero-sized dimensions (that is, should they return the lower and upper bounds as specified by the user)? (2) If the answer to the first question is No, what is the technical reason for LBOUND returning 1 and UBOUND returning 0 for a zero-sized dimension? ANSWER: (1) No. (2) There are three characteristics of each dimension of an array: the lower bound, the upper bound, and the extent. An implementation can calculate the address of an array element by maintaining the lower bound and upper bound or by maintaining the lower bound and the extent. If the standard were to require that the UBOUND intrinsic function return the declared or calculated upper bound, it would preclude implementations from maintaining dimension information via the lower bound and extent. EDIT(S): None. SUBMITTED BY: L. R. Rolison HISTORY: 93-270 m127 submitted 93-324 m127 response approved uc 000124 HELD 94-034 m128 X3J3 ballot passed 25-2 94-160 m129 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: WG5 approved; ready for SC22 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 95-281 m135 WG5 ballot approved -------------------------------------------------------------------------------- NUMBER: 000159 TITLE: May undefined expressions be used as arguments to INQUIRY functions KEYWORDS: inquiry functions DEFECT TYPE: Erratum STATUS: Published QUESTION: Section 13.7.2 Numeric inquiry functions contains the phrase "The value of the arguments to these functions need not be defined", and section 13.8.5 Array inquiry functions contains the similar phrase "The values of the array arguments to these functions need not be defined" One intent is to allow inquiries about the "static" properties of variables, for example: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA)) CHARACTER*(DIGITS(AA)) CC ... where the properties of BB and CC don't depend on the numerical values of AA. However, since the arguments to functions can also be expressions, may the expressions be undefined in the more traditional sense of not having a defined result value? Consider programs like: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA + 1.0)) CHARACTER*(DIGITS(AA + 1.0)) CC ... where the expression "AA + 1.0" is undefined in the normal sense of the word since AA is undefined. Must a processor accept programs where actual argument expressions (involving one or more operators or functions references, as opposed to expressions consisting of a single variable reference) would, if evaluated, use undefined variables or produce undefined results? ANSWER: No, the intent was only to include inquiries about the attributes of undefined variables in the set of allowed inquiries. Discussion: That the resulting text applies to all expressions was unintended and edits are provided to correct this. Note that 'variable name' does not permit substrings or section-subscripts. Edits are not provided for the PRESENT or ASSOCIATED inquiry functions; neither of these permit expressions as arguments. EDITS: 1. In section 13.5.4 Character Inquiry Function [184:18-19] replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." 2. In section 13.5.7 Bit Manipulation and Inquiry Procedures [185:4-5] In the paragraph beginning "An inquiry ..." replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 3. In section 13.7.2 Numeric Inquiry Functions [186:7-8] replace the last sentence "The value of ...." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined, if a pointer it may have undefined or disassociated association status, and if allocatable it need not be allocated." 4. In section 13.8.5 Array Inquiry Functions [187:12] replace the second paragraph "The values of ..." with "If an array argument to these functions consists of a single primary (7.1.1.1) that is a variable name, that variable need not be defined." SUBMITTED BY: Dick Hendrickson HISTORY: 93-279 m127 submitted 94-017 m128 proposed response 94-206 m129 vote on response in 94-017, approved u.c. 94-221 m130 X3J3 ballot, approved 21-2; accept Martin and Shepherd edits N977 m131 edits 2 and 3 changed to incorporate edit from item 108 N984 m131 WG5 approved --------------------------------------------------------------------------------