PC File: 94-006a4.100 Archive: 94-006r4.A100 -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Erratum STATUS: Returned by WG5 for X3J3 reconsideration QUESTION: What is the behavior of the ASSOCIATED intrinsic function for zero-sized arguments? Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWERS: Answer 1: The one-argument form of ASSOCIATED is intended to return a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. Answer 2: No; if both arguments are zero sized, the result is either false or undefined. The following edits clarify the intent. Answer 2a: The result is false because P1 and P2 do not have the same shape. Answer 2b: The result is undefined in this case. EDITS: 1. Section 13.13.13 Case (ii) [198:37], replace by If TARGET is present and is a nonzero-sized target, the result is true if POINTER is currently associated with TARGET. If TARGET is zero sized, but has the same type, type parameters, rank, and shape as POINTER, the result is undefined. Otherwise, the result is false. 2. Section 13.13.13 Case (iii) [199:1], replace by If TARGET is present and is a pointer, the result is true if both POINTER and TARGET are currently associated with the same nonzero-sized target. If the targets are zero sized and have the same type, type parameters, rank, and shape, the result is undefined. Otherwise the result is false. The result is also false if either POINTER or TARGET is disassociated. SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 m129 WG5 #549 email, 94-4-21, J Martin, failed WG5 ballot m129 WG5 #550 email, 94-4-26, J Martin, failed WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: The definition of specification statement has been corrected so that the suggested (but incomplete) edits are not required. EDITS: 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D -------------------------------------------------------------------------------- NUMBER: 000105 TITLE: Parallel evaluation of operands and arguments KEYWORDS: expression evaluation, argument - actual evaluation, function, parallel, concurrent DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Question 1. Does Fortran permit concurrent evaluation of operands in expressions and of actual arguments of functions? Question 2 Is the following program standard conforming? PROGRAM TEST INTEGER F,M PRINT *, F(1,M) + F(2,M) END FUNCTION F(X,M) INTEGER F,X,M M = X*X F = M+M RETURN END ANSWER: Answer 1 Yes, the standard permits a wide variety of expression evaluation models. Answer 2 No, the specific example provided is not standard conforming. Discussion: Sections 7.1.7.1, 12.4.2 and 12.5 provide information on rules for expression evaluation and argument association. Annex C section C.12.5 attempts to make it clear what was intended. The use of concurrent, parallel or "lazy" evaluation of expressions is permitted in a standard conforming Fortran processor. In the example provided in the question the PRINT statement is not standard conforming. Section 7.1.7 contains the following prohibition: The evaluation of a function reference must neither affect nor be affected by the evaluation of any other entity within the statement. EDITS: None. SUBMITTED BY: R. L. Page HISTORY: Contributions to the discussion provided by Brian Smith 92-269 (jw note) 92-327 (jw note) 93-079r1 m124 Type changed from Amendment to Interpretation m124 Approved by unanimous consent 93-111 m125 ballot accepted with Kelble, Rolison edits 94-160 m129 WG5 ballot approved with Shepherd edit 94-180 m129 Shepherd edit as per WG5 ballot -------------------------------------------------------------------------------- NUMBER: 000114 TITLE: subsumed by 000012 KEYWORDS: DEFECT TYPE: STATUS: Subsumed QUESTION: ANSWER: EDIT: SUBMITTED BY: Peter Griffiths HISTORY: ui-98 (131, 120-43) (jw note) 120-99 Initially drafted 92-288 m123 Submitted, approved uc, subsequently questioned in letter ballot 93-074 m124 Revised, adopted by uc 93-228 m126 revised to make 12, 114, 134 consistent, approved uc 93-255r1 m127 ballot failed 21-3 m127 subsumed by 000012 -------------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) P = Q ANSWER: Only case (3) is conforming. DISCUSSION: The phrase "partial statements," used in 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. Regarding case (3), it was intended that the semicolon separator be optional. It is possible to reword the first sentence of 3.3.2.2 (and 3.3.1.2) to completely 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, as is case (3), and cases (1) and (2) 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 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." 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 -------------------------------------------------------------------------------- NUMBER: 000122 TITLE: Intrinsic procedures in modules KEYWORDS: intrinsic procedure, module DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 soley 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 -------------------------------------------------------------------------------- NUMBER: 000123 TITLE: Result of INT(A) not equal to A for non-default integers KEYWORDS: INT intrinsic DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000124 TITLE: Result of LBOUND for assumed-size arrays KEYWORDS: LBOUND intrinsic, array assumed-size DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 the upper bound for dimension DIM is *; otherwise, (b) 1." 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 -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER: Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute. 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. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If the dummy argument has the TARGET attribute and 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 the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute. 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 -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: Hold - Returned by WG5 for X3J3 reconsideration 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: 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 may 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: The first sentence of Section 11 indicates that a module is a program unit. Section 14.1.1 defines global entities. The definition includes module names because the definition lists program units. Section 14.1.2 states that a name that identifies a global entity must not be used to identify a local entity of class(1). 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 would mean that the following: MODULE ABC REAL ABC END MODULE 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. A correction to that section has rectified the omission (defect item 90). 12.1.2.2.1 now clearly states that the appearance of a name as the in a will prevent 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 -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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. EDITS: 1. 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" 2. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 3. In section 7.1.6.1, in the second list, in item 7 [78:11], change: "." to: ", or" 4. In section 7.1.6.1, in the second list, add item 8 [78:11+]: "(8) An implied-DO variable where the bounds and strides of the corresponding implied-DO are initialization expressions." 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 -------------------------------------------------------------------------------- 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: X3J3 consideration in progress 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 it is executed. REFERENCES: ISO/IEC 1539:1991 (E) sections 1.4 and 5.1.2.3. EDITS: 1. Section 1.4 second paragraph, first sentence [2:4] change 'uses' to 'contains' 2. Section 1.4 sixth paragraph, first sentence [2:39] change 'use' to 'contain' 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 -------------------------------------------------------------------------------- NUMBER: 000136 TITLE: scalar-structure-component in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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: The standard is insufficient in specifying the use of DATA implied-DO variables in subscript expressions but the insufficiency need not necessarily be corrected via the addition of a constraint. This was an oversight both in FORTRAN 77 and in Fortran 90 and 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. Allowing the standard-conforming form as shown in the example was not intended and provides no useful language functionality. Note that by clarifying the intent of the standard via application of the edit produces an explicit restriction in Fortran 90 that, although intended by FORTRAN 77, was not explicitly stated. The relevant text from FORTRAN 77 is given on page 9-3, lines 13-16: Each subscript expression in the list must be an integer constant expression, except that the expression may contain implied-DO-variables of implied-DO lists that have the subscript expression within their ranges. Note that the text states that subscript expressions in a DATA implied-DO "may" contain implied-DO variables. This use of "may" was intended to allow a variable into what would otherwise be a constant expression. But it could also be taken to mean that a subscript expression "may" contain references to implied-DO variables, but the are not "required" to do so. For example, a subscript expression of the following form is allowed: DATA ((ARRAY(I+J, 3), I = 1, 10), J = 11, 21) ... This same concept was carried forward to the Fortran 90 standard. It was not the intent in either standard, however, to allow the case where no subscript expression contains a reference to the implied-DO variable as shown in the example. EDIT: In section 5.2.9, following the last paragraph [52:44+], add the following text: The of a must appear in at least one of each and contained within the range of the . Example: INTEGER ARRAY_1(5,5), ARRAY_2(5), ARRAY_3(10) DATA ((ARRAY_1(I, J+1), I = 1, 5), ARRAY_2(J+1), J = 0, 4) ... DATA ((ARRAY_3(I + J*1), I = 1, 2), J = 3, 4) ... TYPE SMALL INTEGER I(2) REAL R END TYPE TYPE(SMALL) GROUP(3) DATA ((GROUP(J)%I(K), K = 1, 2), J = 1, 3) ... Since ARRAY_1 is within the range of both I and J, its subscript list must contain references to both I and J, but since ARRAY_2 is only within the range of J, its subscript list need only reference J. The second DATA statement demonstrates that the DATA implied-DO variables need not be referenced in separate subscript expressions. The third DATA statement demonstrates that the implied-DO variables can be referenced in separate subscript lists of the same designator. In this case, note too that both J and K must be referenced in the designator since it falls within the range of both implied-DO variables. SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 -------------------------------------------------------------------------------- NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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: LOGICAL is not a valid type for any SIN intrinsic; an edit is provided below to clarify that such a specification is not permitted. While the Fortran 77 standard was interpreted as allowing such specifications, no semantics were defined; thus 'LOGICAL' in this example was a noise word. In the absence of defined semantics and the inconsistency of the construct (in apparently specifying a non-existant intrinsic), no occurrences, other than those resulting from coding errors or in testing that interpretation, are anticipated in existing Fortran programs. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1,5.1.2.10, 5.1.2.11, 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'object name' with '' [48:26] 2. Section 5.1.2.11 Replace 'object name' with '' [48:30] 3. Section 5.1, second paragraph following the constraints [40:35-36] Replace 'An explicit type declaration statement is not required; however it is permitted. Specifying a type for a generic intrinsic function name in a ...' with 'An explicit type declaration statement confirming that type for either a specific or generic name is not required; however it is permitted. Such a ...' 4. Section 1.4.1 [3:32+] Add (6) 'FORTRAN 77 permitted the specification of a type for an intrinsic function even when there was no function defined for that type. For example: INTRINSIC SIN LOGICAL SIN This International Standard specifies (5.1) that a type declaration for an intrinsic function may only confirm the type of an existing function. Thus a standard-conforming FORTRAN 77 program specifying a type that is not defined for an intrinsic function does not conform to this International Standard. 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. -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Section 6.1.2 (page 63) states: A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute. A constraint following R505 (page 40) states: Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified. This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: Neither is contradicted. Discussion: The syntax rules for a derived type definition (R422 - R429) permit only the POINTER and DIMENSION attributes for a component, thus the TARGET keyword must not appear in a type definition. However, every pointer object has the TARGET attribute implicitly. Section 6.3.1.2 (page 68) states: Allocation of a pointer creates an object that implicitly has the TARGET attribute. While it is not possible to declare an object to have both the POINTER and TARGET attribute, every allocated pointer object possesses the TARGET attribute, so there is no problem with specifying the TARGET attribute for a derived type object containing a pointer component. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 6.1.2, 6.3.1.2 EDITS: None SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 cancelled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Is there a conflict between the rule given in section 14.1.2, lines 29-31, page 241, and that given is section 12.2.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 that a global name cannot be the same as a local name of class 1, unless it is an external function name. >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 above, one might conclude that a generic name cannot be the same as on 12.3.2.1, pg 168, 1. 37-39 states explicitly that "a generic name may be the same as any one of the procedure names in the interface block..." ANSWER: REFERNCES: ISO/IEC 1539:1991, sections 12.3.2.1, 14.1.2, and 14.1.2.2 EDITS: SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-188 m126 submitted -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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 -------------------------------------------------------------------------------- NUMBER: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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 either within the module or 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, if the entity is accessible from the module and otherwise, yes for references within the module. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider attributes specified by executable statements. It was the intent that attributes of use associated entities 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. REFERENCES: ISO/IEC 1539:1991 (E) section 11.3.2, 5.2.3 EDIT: Add at the end of the first paragraph of 5.2.3 [49:31]: "If a procedure is accessible from a module, then within the scoping unit of the module one of the following must be true: (1) if it is an intrinsic procedure, it must be given the INTRINSIC attribute or be used as an intrinsic procedure (2) the procedure must have an explicit interface (3) the procedure must be given the EXTERNAL attribute and if it is a function it must be explicitly declared in a type declaration statement. SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text does prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements you cite. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence you cite is corrected with the supplied edit. (c) No, but fragments such as the one you provide are disallowed for other reasons as elaborated in the discussion of part (a). Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, and intrinsic procedures. * Named constant Section 5.2.1.1 states: A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association. Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. Likewise, no USE statement could have occurred so use association does not apply. This means that if a named constant appears in the of a FUNCTION statement, the function must be a module procedure or an internal subprogram, and the named constant must exist in (be accessible to) the containing scoping unit. This also means that a named constant must not appear in a of a FUNCTION statement of an interface body because an interface body does not access names via host association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument but this part of the rule does not apply to a on a FUNCTION statement because a subobject can not be referenced before its parent object is declared and since the FUNCTION statement is the first statement of the subprogram, such a declaration could not have occurred. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above such a subobject designator can not appear in the expression. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable, but by the same reasoning as above, a subobject of a use associated variable can not appear in the expression. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) The discussion for part (a) describes which variable I in the example is being referenced in the of the FUNCTION statement. EDIT: Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], replace "in an interface body (12.3.2.1) or in the specification part of a subprogram" with "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116 m129 X3J3 ballot failed 22-1 (email from Shepherd, 116r1) -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Conformance KEYWORDS: conformance, derived type DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress 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 type-name must not be the same as the name of any intrinsic type .... 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 type-name, ABC, is the same as the name of an intrinsic type? ANSWER: No. The constraint pointed to in the question is overly broad. There is no syntactic ambiguity; the constraint exists only to disallow forms that might cause confusion when the program source is read by a user. An edit is provided to restrict the scope of the constraint. Additional edits clarify that processors can allow additional intrinsics (while already referenced in section 1.4, other text is contradictory). EDITS: 1. In section 1.4, change the paragraph beginning "Note that" so that added data types are described in a manner parallel to added intrinsic procedures in the prior paragraph. [2:42] change "a nonstandard data type" to "additional intrinsic data types" 2. In section 2.5.7 [16:35-36] change "International Standard" to "International Standard or by the processor" 3. In section 4.4.1, change the fifth constraint following R424 to: [33:12-13] Constraint: A derived type must not be the same as the name of any intrinsic type defined in this standard nor the same as any other accessible derived type . SUBMITTED BY: Dick Weaver HISTORY: 93-209 m126 submitted 93-317 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 -------------------------------------------------------------------------------- NUMBER: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: Consider the following program : program ex1 interface sqrt real function usersqrt(i) integer i endfunction usersqrt endinterface call test contains subroutine test intrinsic sqrt write(*,*) sqrt(16) endsubroutine test end As I read 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. If I understand 14.1.2.4.1 the reference to sqrt(16) should resolve to usersqrt i.e. even though the user specifies intrinsic for sqrt he ends up with a reference to a user procedure. Isn't that a little bit misleading to say the least? Contrast that with the following example where sqrt has been replaced by csqrt: program ex2 interface csqrt complex function usersqrt(i) integer i endfunction usersqrt endinterface call test contains subroutine test intrinsic csqrt write(*,*) csqrt(16) endsubroutine 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 my interpretation of the standard correct? If so, was this the intended behaviour? If it was won't users find this very confusing? ANSWER: EDITS: SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (p228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor- dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) This is processor dependent. The standard states: "If no argument is present, the processor sets the seed to a processor dependent value." [228:13] This leaves the value of the seed and the method of generating that value up to the processor. Therefore, the standards committee cannot rule on whether X = Y or not. Different processors will handle this in different ways. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDITS: In the description of RANDOM_SEED after RANDOM_NUMBER, add the text : [228:2] "The pseudo random number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) it is not required that SEED1 equal SEED2. However it is required that calls to RANDOM_NUMBER immediately after a call to RANDOM_SEED with a seed that is either SEED1 or SEED2 return the same sequence of pseudo random numbers. In particular, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) it is required that X1=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 -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function DEFECT TYPE: STATUS: X3J3 consideration in progress QUESTION: In the statement function, page 182: question 1: in the first constraint variables must be scalar, but not constants. Why? question 2: Where, in the first constraint, it states: "... scalar-expr must be composed of ...." does "composed" mean the primaries of that expression or does it extend to primaries of contained expressions? ANSWER: EDIT: SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted --------------------------------------------------------------------------------