PC File: 95-006a4.100 Archive: 95-006r4.A100 -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: Although X3J3 agrees with the concept of the proposed change, the committee feels that the changes required will be more pervasive than simply changing the phrases cited in the Question. The changes are pervasive enough that they are best not attempted in a corrigendum to Fortran 90. Due to the late stage of processing of the draft Fortran 95 standard, the committee believes that it will not have time to adequately address these changes for inclusion in the Fortran 95 standard. Therefore, we are adding the suggested changes to a committee standing document entitled "Editorial Considerations for 9x Draft Revision X3J3/008". (Note that although the name of the document needs to be updated, the document continues to exist as a standing document to be used in the preparation of the Fortran 2000 draft standard.) The following edits will NOT be applied to the Fortran 95 draft standard. They exist in this document so that this document can be added to the 008 without loss of the work that was begun to apply the general changes noted in the Question. 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. Note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' EDITS: None SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D 95-162 m133 Response revised to state the suggestions will be added to X3J3 standing document 008, passed u.c. 95-183 m134 X3J3 ballot passed 16-1 -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION:Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER:Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute, and is either scalar or is an assumed-shape array. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. An earlier answer to this defect included different wording for the start of the second paragraph of edit 3: "If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript:" and did not include the paragraph: "If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent." An earlier answer to this defect included different wording for the first paragraph of edit 4. "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript." The earlier versions of edits 3 and 4, along with edits 1 and 2 were included in corrigendum 2. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If the dummy argument has the TARGET attribute and is either scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute and is either scalar or is an assumed-shape array, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2. 95-177 m134 revised response and edits, approved 14-2 95-256 m135 X3J3 ballot, approved 15-1 -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following program fragment: MODULE ABC INTEGER G END MODULE PROGRAM MAIN USE ABC ! Contains name ABC REAL ABC ! Contains name ABC END PROGRAM Question 1: Is a module a global entity? Question 2: In the above program fragment, the name ABC in the main program is both the name of a module and of a local entity (of class (1)). May a local entity of class (1) in a scoping unit have the same name as a module accessed by that scoping unit? Question 3: May a module be accessed in a scoping unit that also accesses a local name that has the same name as the module? Specifically, in the example below can subroutine SUB reference the variable ABC? MODULE ABC INTEGER G END MODULE PROGRAM MAIN REAL ABC ! Contains name ABC ... CONTAINS SUBROUTINE SUB USE ABC ! Contains name ABC ... END SUBROUTINE END PROGRAM ANSWER: Answer 1: Yes, a module is a global entity. Answer 2: No, a local entity of class (1) in a scoping unit must not have the same name as a module accessed by that scoping unit. Answer 3: No, a module can not be referenced in a USE statement in a scoping unit that also accesses a local name that has the same name as the module. Variable ABC is not accessible by that name in the subroutine SUB. Discussion: Discussion for Answer 1: The second sentence of Section 11 states that a module is a program unit. Section 14.1.1 defines global entities. The definition includes modules because the definition lists program units. In addition, the response to Defect Item 90 clarified the fact that a module name is a global name by changing the following text in 12.1.2.2.1 [163:39-164:1] from "A name that appears in the scoping unit as an in an is a global name..." to "A name that is declared to be an external procedure name (by an or an ), or that appears as a in a is a global name..." Discussion for Answer 2: Answer 1 established that a module is a global entity and that a module name is a global name. Section 14.1.2 states "... a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." Discussion for Answer 3: There are two general cases where a local name could conflict with a module name. The first is as follows where the local name is contained in the module itself: MODULE ABC REAL ABC END MODULE and the second is as in the specific example provided above in Question 3. Section 11.3 [157:24-26] states: "The module name is global to the executable program, and must not be the same as the name of any other program unit, external procedure, or common block in the executable program, nor be the same as any local name in the module." This means that the first case is not standard conforming. Section 14.1.2 [241:29-31] states: "Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." The original description of host association in 12.1.2.2.1 inadvertently failed to account for module names. The response to Defect Item 90 supplies edits to rectify the omission. With those edits, 12.1.2.2.1 now clearly states that the appearance of a name as the in a prevents access by host association to an entity of the same name in the host scoping unit. EDIT: None SUBMITTED BY: Larry Rolison in X3J3/93-037 at m124. HISTORY: 93-037 m124 Submitted 93-097 m124 Draft response failed 93-148 m125 Revised response, withdrawn 93-235 m126 Revised response based on edit in item 82. approved uc 93-255r1 m127 ballot passed 24-0 HOLD per 82 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot failed HOLD per 90 95-139 m133 Revised response based on edits in Defect Item 90, draft response approved uc 95-183 m134 X3J3 ballot passed 17-0 -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Erratum STATUS: X3J3 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: No, the component reference does not contradict either the constraint or the cited text from 6.1.2. The cited text from 6.1.2 is not needed and an edit provided deletes it. Discussion: The constraints that follow a syntax rule, or a set of syntax rules, are syntactic constraints and apply only to the syntax rules they immediately follow. Thus, the constraints that follow rules R501 through R505 at the beginning of section 5 apply only to those rules. This means they apply only to type declaration statements. Since a derived type component is part of a derived type definition (which is not a type declaration statement), the constraints do not apply to derived type components. The rule that prevents an entity from having conflicting attributes when applied by multiple specification statements is found in 5.2: "The combination of attributes that may be specified for a particular entity is subject to the same restrictions as for type declaration statements regardless of the method of specification." The sentence from 6.1.2 cited in the question is not necessary (and is thus deleted by an edit) because the "barrier" to a reference or definition of a structure component is at the structure (parent) level and thus no additional "barrier" is needed at the component level. Thus, for example, specifying an attribute such as TARGET at the structure level is sufficient; there is no need to "trickle down" the attribute to components of the structure (and indeed if a component were treated as an independent variable, the combination of TARGET and POINTER would otherwise be prohibited). The philosophy that an attribute applied at the structure (parent) level is all that is needed is borne out by the following: TARGET: Section 7.5.2, second constraint states: "The must have the TARGET attribute or be a subobject of an object with the TARGET attribute ..." PARAMETER: Rule R601 and the constraints associated with it state that neither an nor a can have the PARAMETER attribute and that a must not be a subobject designator whose parent is a constant. INTENT(IN): The response to defect item 135 added a constraint to 5.1.2.3 that states that a dummy argument with the INTENT(IN) attribute, or a subobject of such an object, must not appear in any assignment context. EDIT: In section 6.1.2, in the paragraph following the last constraint [63:15-17], delete the sentence that starts: "A structure component has the INTENT..." SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 canceled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 95-034r1 m132 X3J3 ballot failed 8-12 95-033 m132 Revised response, straw vote on intent 5-2-7 95-092 m132 Revised discussion, approved u.c. 95-101 m133 X3J3 ballot failed 11-7 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Is there a conflict between the rule given in section 14.1.2, page 241, lines 29-31, and that given in section 12.3.2.1, page 168, lines 37-39, as they apply to generic and specific names? Discussion: In a generic interface block, if a specific name is an external procedure, then it is a global entity. The generic name is a local entity of class 1. Section 14.1.2, lines 29-31, page 241 states: "Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." >From the reference given for external function name (14.1.2.2), it appears that the exception is meant to apply only within the external function itself. >From the text in 14.1.2, one might conclude that a generic name cannot be the same as one of the specific procedure names specified in the interface block. However, 12.3.2.1, page 168, lines 37-39 states explicitly that "a generic name may be the same as any one of the procedure names in the interface block..." ANSWER: The text in 14.1.2 was intended to allow this case. An edit is provided to clarify this. EDIT: In 14.1.2, paragraph 2, line 1 [241:29], before "or" add ", an external procedure name that is also a generic name (12.3.2.1),". SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-188 m126 submitted 94-308 m131 proposed response 94-358 m131 clarified text of question, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association 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 seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.2.1.1 states: A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association. Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. Likewise, no USE statement could have occurred so use association does not apply. This means that if a named constant appears in the of a FUNCTION statement, the function must be a module procedure or an internal subprogram, and the named constant must exist in (be accessible from) the host scoping unit. This also means that a named constant must not appear in a of a FUNCTION statement of an interface body because an interface body does not access names via host association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable, but by the same reasoning as above, a subobject of a use associated variable can not appear in the expression. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds of the parent object." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c 95-034r1 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Intrinsic Type Names KEYWORDS: conformance, intrinsic type, derived type, names - class DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Section 1.4 "Conformance", third paragraph following the list, states: For example, a standard-conforming processor may allow a nonstandard data type. Section 4.4.1 "Derived-type definition", fifth constraint following R424, states: A derived type must not be the same as the name of any intrinsic type... Suppose the program fragment TYPE ABC INTEGER XYZ END TYPE is taken to a processor that, as allowed by 1.4, has defined the nonstandard intrinsic type "ABC". Is it intended that this processor reject the program for the reason that a derived type , ABC, is the same as the name of a nonstandard intrinsic type? ANSWER: No. Vendor-specific types which behave like intrinsic types are not strictly intrinsic types, because the entire list of intrinsic types is enumerated in section 4. Section 4 states: "An intrinsic type is one that is predefined by the language." EDITS: None SUBMITTED BY: Dick Weaver HISTORY: X3J3/93-209 m126 submitted X3J3/93-317 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-340 m131 Revised response submitted, approved u.c. 95-034r1 m132 X3J3 ballot approved 19-1, with edit -------------------------------------------------------------------------------- NUMBER: 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 (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 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) No, it is not the intent of the standard that X must equal Y after 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 argumentless calls to RANDOM_SEED. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDIT: In section 13.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 and of argument GET from the seed is performed in a processor dependent manner. The value specified by PUT may not be the same as the value returned by GET. For example, following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. If the GET argument corresponding to PUT argument P is used as the PUT argument in a subsequent call to RANDOM_SEED the sequence of pseudorandom numbers generated will be the same as for P. For example, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot failed 13-7 95-142r1 m133 revised response, approved 10-2 95-183 m134 X3J3 ballot failed 12-5 -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function, primary DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: In section 12.5.4, the first constraint, it states: "... may be composed only of ...." does "composed" mean the primaries of that expression or does it extend to primaries of contained expressions? ANSWER: "Composed" is not defined by the standard. An edit is provided that eliminates the use of "composed". EDIT: In section 12.5.4, in the first sentence of the first constraint, [182:4] change "The may be composed only of" to "The primaries of the must be". SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted 94-341 m132 Question revised, response submitted, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit --------------------------------------------------------------------------------