PC file: 95-006a5.0 Archive: 95-006r5.A0 -------------------------------------------------------------------------------- NUMBER: 00000e TITLE: Rejected Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Should the following be added to the list of edits? 8. In 13.13.85 RANGE change 'Returns the decimal exponent range in the model ...' to 'Returns the upper bound of the decimal exponent range of the model ...' [228:20] Rationale(1): a range has two values; RANGE returns only one. Rationale(2): there is not a decimal range in the model, see 13.7.1, but a decimal range can be calculated. Thus the change from 'in' to 'of'. 9. In 13.13.79 PRECISION change 'Returns the decimal precision in the model ...' to '............................. of .............' [226:4] Rationale: same as for RANGE, above. ANSWER: This item collects failed "minor edits and corrections" so that the reasons for failing them can be recorded for historical purposes. No further voting is needed for items in this list. No, 8 and 9 should not be added. The use of 'range' is consistent with other uses in the standard and is meant to convey an entire range of values not just 2. The change from 'in' to 'of' is too small a change to be included at this time and would best be addressed in a future standard. EDITS: None SUBMITTED BY: HISTORY: 94-028 m128 additional items 8-9 -------------------------------------------------------------------------------- NUMBER: 000027 TITLE: Requirements for pointer and target association KEYWORDS: POINTER attribute, TARGET attribute, pointer association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 QUESTION: If PTR has the POINTER attribute and TGT has the TARGET or POINTER attribute, under which of the following other conditions are PTR and TGT considered to be pointer associated, i.e., under which of the following conditions does ASSOCIATED(PTR, TGT) return a value of .TRUE.: a) PTR and TGT have different types? b) PTR and TGT have different type parameters? c) PTR and TGT have different ranks? d) PTR and TGT have different sizes? e) PTR and TGT have different shapes? f) PTR and TGT have different bounds? g) PTR and TGT refer to the same set of array elements/storage units, but not in the same array element order? h) PTR and TGT have array elements/storage units whose range of memory addresses overlap, but they have no identical array elements/storage units? i) PTR and TGT have at least one but not all identical array elements/storage units and all the identical elements have the same subscript order value in both PTR and TGT? j) PTR and TGT have at least one but not all identical array elements/storage units but not all the identical elements have the same subscript order value in both PTR and TGT? ANSWER: Any of the above conditions except for f) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. In determining whether a pointer and a target are associated, the bounds are relevant only for determining which elements are referenced. The extents of each dimension of PTR and TGT must be the same, thus their shapes must match which is covered by condition (e). If TGT is zero sized, ASSOCIATED (PTR, TGT) returns .FALSE.. Discussion: It is the intent of the standard that the two argument form of the ASSOCIATED intrinsic function returns true only if the association of POINTER and TARGET is as if the pointer assignment statement POINTER => TARGET was the last statement executed prior to the execution of the statement invoking the ASSOCIATED function. This is not clear in the definition of the ASSOCIATED intrinsic or elsewhere in the standard. Clarifying edits are provided. In the example program fragment below, for the first invocation of the ASSOCIATED function the result is true, the second invocation of the function is invalid as the type, type parameters and rank of IR and CX are not the same. SUBROUTINE SUB () INTEGER, TARGET :: I REAL,TARGET,DIMENSION(2) :: R INTEGER, POINTER :: IP REAL, POINTER, DIMENSION(:) :: IR COMMON /BLOCK/ I, R IP => I IR => R(:) CALL INNER() CONTAINS SUBROUTINE INNER() INTEGER,TARGET :: J COMPLEX,TARGET :: CX COMMON /BLOCK/ J, CX PRINT *, ASSOCIATED (IP, J) ! true PRINT *, ASSOCIATED (IR, CX) ! error, though the target of IR and ! CX occupy exactly the same storage ! units in the same order END SUBROUTINE INNER END SUBROUTINE SUB EDITS: 1. In section 13.13.13 [198:31] in the description of the TARGET dummy argument add ", and have the same type, type parameters, and rank as POINTER" following "must be a pointer or target" 2. In section 13.13.13 replace Case (ii) with [198:35-36] "Case (ii): If TARGET is present and is a scalar target, the result is true if TARGET is not a zero sized storage sequence and the target associated with POINTER occupies the same storage units (there may be only one) as TARGET. Otherwise the result is false. If POINTER is disassociated, the result is false." 3. In section 13.13.13 replace Case (iii) [199:1-3] with "Case (iii): If TARGET is present and is an array target, the result is true if the target associated with POINTER and TARGET have the same shape, are not of size zero or arrays whose elements are zero sized storage sequences, and occupy the same storage units in array element order. Otherwise the result is false. If POINTER is disassociated, the result is false. Case (iv): If TARGET is present and is a scalar pointer, the result is true if the target associated with POINTER and the target associated with TARGET are not zero sized storage sequences and they occupy the same storage units (there may be more than one). Otherwise the result is false. If either POINTER or TARGET is disassociated, the result is false. Case (v): If TARGET is present and is an array pointer, the result is true if the target associated with POINTER and the target associated with TARGET have the same shape, are not of size zero or arrays whose elements are zero sized storage sequences, and occupy the same storage units in array element order. Otherwise the result is false. If either POINTER or TARGET is disassociated, the result is false. " SUBMITTED BY: Jon Steidel, 120-JLS-4 (120.022) HISTORY: 120-LJM-3A (120.081A) m121 Original response proposed 92-061 (121-ADT-9) p9 & X3J3/92-061 Questioned response (121-ADT-13) item 27 92-093A m121 Approved 92-329 (jw note) m123 Approval rescinded at m123 (uc) 93-099r1 m124 Revised response adopted (15-2) 93-111 m125 ballot failed, returned to subgroup 93-135r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response was prepared and adopted 15-3. 93-255r1 m127 ballot failed 17-7 94-289 m130 revised answer, approved u.c. 94-306 m131 X3J3 ballot failed 16-3 95-281 m135 revised response, added edits, WG5 approved ------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 95-044 m132 WG5 ballot failed, text in Answer 4 and discussion needs revision -------------------------------------------------------------------------------- NUMBER: 000070 TITLE: Characteristics specified by interface bodies KEYWORDS: characteristics, array bounds, array shape, function result DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 12.3.2.2 indicates that an interface body specifies all of a procedure's characteristics and that the characteristics must be consistent with those in the procedure definition. Are the following code fragments standard conforming? (a) PROGRAM FRED INTERFACE SUBROUTINE SUB (ARR,J) INTEGER ARR(1:) END SUBROUTINE END INTERFACE INTEGER ARR(10) CALL SUB(ARR,2) END PROGRAM SUBROUTINE SUB(ARR, J) INTEGER ARR(J:) ... END SUBROUTINE SUB (b) FUNCTION C1( ) CHARACTER(*) C1 ... END FUNCTION C1 FUNCTION C2(N) CHARACTER(N) C2 ... END FUNCTION C2 SUBROUTINE CALLER( ) INTERFACE FUNCTION C1( ) CHARACTER(*) C1 END FUNCTION FUNCTION C2(N) CHARACTER(2) C2 END FUNCTION END INTERFACE CHARACTER(5) CC CC=C1( )//C2(2) ANSWER: (a) This example is standard conforming. (b) This example is not standard conforming. Discussion: (a) 12.2.1.1 states that the characteristics of a dummy data object include its shape, and that if the shape is assumed then that is a characteristic. Section 2.4.5 states that the shape of an array is determined by its rank and extent in each dimension (but not by its bounds, 5.1.2.4.2). Both the interface block for SUB and the definition of SUB describe the shape of ARR as assumed, so they are describing the same shape, and the program is standard conforming. It is possible to read the second sentence in 12.2.1.1 as requiring bounds to match. This was not intended. An edit to that section (defect item 49) has clarified that it is the shape resulting from the bounds specifications that is a characteristic and not the bounds themselves. (b) Section 12.2.2 states that the characteristics of a function include whether or not the function result value is a character of assumed length. So the interface body for function C1 must indicate that C1 is of assumed length. However, item (3) in 5.1.1.5 indicates that scoping units that invoke an external character function of assumed length must have access to a declaration of the function name with a length type parameter value other than *. An edit is included to clarify this restriction. In addition, the interface for C2 does not conform to the standard as the length of C2 specified as 2 is not consistent with the length specified as N within the function definition. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.4.5, 5.1.1.5, 5.1.2.4.2, 12.2.1.1, and 12.2.2. EDITS: In section 5.1.1.5 item (3), add to the end [43:5]: "Note that the interface for such a function cannot be specified in an interface body." SUBMITTED BY: Graham Barber (a), Janice Shepherd (b) HISTORY: 92-264 Question (a) originally posed 92-46 Question (b) originally posed in e-mail collection ui 48 (jw note) 92-283 Response proposed m123 Approved by unanimous consent 93-018 Response questioned by John Reid in 93-103 Revised response proposed m124 Approved by unanimous consent 93-111 m125 ballot, return to subgroup, Leonard comment, coordinate with 0000049? 94-060 m128 New edit in 0000049 referenced ------------------------------------------------------------------------------- NUMBER: 000081 TITLE: Pointer actual argument overlap KEYWORDS: pointer, target, argument - actual, argument - dummy, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 QUESTION: Section 12.5.2.9, Restrictions on entities associated with dummy arguments, clearly states that if there is partial or complete overlap between actual arguments associated with two different dummy arguments of the same procedure, the overlapping portions may not be defined, redefined, or undefined during the procedure execution. It continues: "This restriction applies equally to pointer targets. For example, in REAL, DIMENSION (10), TARGET :: A REAL, DIMENSION (:), POINTER :: B, C B => A (1:5) C => A (3:9) CALL SUB (B, C) B (3:5) cannot be defined because it is part of the actual argument associated with the second dummy argument. C (1:3) cannot be defined because it is part of the argument associated with the first dummy argument. A (1:2) [which is B (1:2)] remains definable through the first dummy argument and A (6:9) [which is C (4:7)] remains definable through the second dummy argument." Unfortunately, this example does not contain an explicit interface for the called subroutine, nor are there sufficient words to clearly state what is meant by the words and example provided. Question 1: Do the above restrictions hold when both dummy arguments are nonpointers? In this case the following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y END SUBROUTINE END INTERFACE Question 2: Same as question 1, only add the TARGET attribute to one or both of the dummy arguments. The following interfaces may describe SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), TARGET :: X, Y END SUBROUTINE END INTERFACE or INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y TARGET X END SUBROUTINE END INTERFACE Question 3: Do the above restrictions hold *upon entry* when both dummy arguments are pointers? That is, *upon entry* to SUB, is it safe to assume that pointer dummy arguments do not have overlapping elements which may get defined during execution of SUB? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:), POINTER :: X, Y END SUBROUTINE END INTERFACE Question 4: Same as question 3, but one dummy argument is a pointer, one has the target attribute? *Upon entry* to SUB, is it safe to assume a pointer dummy argument does not point to any elements of a target dummy argument which may get defined during execution of SUB, but during the execution of SUB such an association may come to exist? The following interface describes SUB. INTERFACE SUBROUTINE SUB (X, Y) REAL, DIMENSION (:) :: X, Y POINTER X TARGET Y END SUBROUTINE END INTERFACE Question 5: Two derived type dummy arguments each have a subobject (or a subobject of a subobject etc.) which are pointers with the same type, kind type parameter, and rank. *Upon entry* to the subroutine, is it safe to assume such pointer subobjects do not have overlapping targets which may get defined? That is, in the following fragment, *upon entry* to SUB, is it safe to assume X%PTR_1 and Y%PTR_2 cannot have overlapping target elements which get defined during execution of SUB? SUBROUTINE SUB (X, Y) TYPE A SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_1 END TYPE TYPE B SEQUENCE REAL, DIMENSION(:), POINTER :: PTR_2 END TYPE TYPE (A) :: X TYPE (B) :: Y ANSWER: There is a deficiency in the standard. The restrictions always apply to the allocation status of the entities, but do not apply to: (1) the values when the dummy argument or a subobject of the dummy argument has the POINTER attribute, (2) the values when the dummy argument has the TARGET attribute, is a scalar or an assumed-shape array and does not have the INTENT(IN) attribute and the actual argument is a target other than an array section with a vector subscript, and (3) the pointer association status. Edits are supplied to correct this. The answers to the specific questions are: Answer 1: Yes for the interface specified. Answer 2: Yes for the allocation status of the entities. Yes for the values except when (2) holds. Answer 3: Yes for the allocation status of the entities. No for the pointer association status. No for the values. Overlapping elements of dummy arguments may be defined during execution of SUB. Answer 4 (first part): Yes for the allocation status of the entities. No for the pointer association status of the entities. No for the value of the pointer argument. No for the value of the target argument when it is not INTENT(IN), it is scalar or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Yes for the value of the target argument in other cases. Answer 4 (second part): Upon entry to SUB, a pointer dummy argument may point to an element of a target assumed-shape dummy argument that is defined during execution of SUB. Answer 5: Yes for the allocation status of the entities. No for the pointer association status of the entities. No for the values. Overlapping elements of pointer components of dummy arguments may be defined during execution of SUB. Discussion: The restrictions of Section 12.5.2.9 on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage. The latter mechanism is usually known as "copy-in/copy-out". The text assumed that the rules applied to an actual argument with the TARGET attribute, too, but defect item 125 has made it clear that this is not the case for all actual arguments with the TARGET attribute and edits are needed in 12.5.2.9. The present text is incorrect for the pointer association status of a pointer dummy argument. The implementation must allow for the pointer association status to be altered through another pointer. The present text is incorrect for the value of a pointer dummy argument. Here, the implementation must allow for the value to be altered through another pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGP) INTEGER, POINTER :: IARGP INTEGER, TARGET :: J IP = 0 ! OK. This alters the value of IARGP, too. It is also incorrect where the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. Here the implementation must allow for the value to be altered through a pointer as in the example INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of IARGT, too. EDITS: 1. In section 12.5.2.9, [180:3-4] Replace the first two lines of item (1) by "No action that affects the allocation status of the entity may be taken. Action that affects the value of the entity or any part of it must be taken through the dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 2. In section 12.5.2.9, [180:32] in the line following the line "DEALLOCATE (A)" change "availability of A" to "allocation of B". 3. In section 12.5.2.9, [180:34-35] in the lines following the line "DEALLOCATE(B)" change ", but would ... attribute." to ". If B were declared with the POINTER attribute the statements DEALLOCATE(A) and DEALLOCATE(B) would both be permitted." 4. In section 12.5.2.9, [180:37] in the second to last paragraph on page 180, after "the same procedure" add "and the dummy arguments have neither the POINTER nor the TARGET attribute". 5. In section 12.5.2.9, [181:8] in line 8 of page 181, after "CALL SUB(B,C)" add "! The dummy arguments of SUB are neither pointers nor targets". 6. In section 12.5.2.9, [181:17-19] Replace the first three lines of item (2) by "If the value of any part of the entity is affected through the dummy argument, then at any time during the execution of the procedure, either before or after the definition, it may be referenced only through that dummy argument unless (a) the dummy argument has the POINTER attribute, (b) the part is all or part of a pointer subobject, or (c) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT(IN), the dummy argument is a scalar object or an assumed-shape array and the actual argument is a target other than an array section with a vector subscript. For example, in" 7. In section C.12.7, [291:40-42] Replace lines 3 to 5 by "The restrictions on entities associated with dummy arguments are intended to facilitate a variety of optimizations in the translation of the procedure, including implementations of argument association in which the value of an actual argument that is neither a pointer nor a target is maintained in a register or in local storage." SUBMITTED BY: Jon Steidel HISTORY: 92-208 m123 Submitted 93-85 m124 Proposed response, withdrawn 93-174 m125 Revised response, withdrawn 93-213 m126 Revised response, adopted by unanimous consent 93-255r1 m127 ballot failed 19-5 94-248 m130 Revised response and edits. 94-282r1 m130 Clarified terminology, approved u.c. 94-306 m131 ballot failed 11-7 94-309r1 m131 modified edits and answer, approved 12-1 94-366r1 m131 First edit replaced with revised text from 94-366r1 approved u.c. 95-034r1 m132 X3J3 ballot failed, 16-4 95-043 m132 revised words of answer/edit (no change in intent) and change status to X3J3 approved; approved 10-4 95-244 m134 Updated answer and edits based on new answer to defect item 125, approved u.c. 95-256 m135 X3J3 ballot failed, 10-6 95-281 m135 revised response and edits, WG5 approved -------------------------------------------------------------------------------- NUMBER: 000096 TITLE: Definition of "Declaration" KEYWORDS: declaration, specification DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: "Declaration" is a significant concept of Fortran 90. Section 5 is titled "Data object declarations and specifications" and what were in FORTRAN 77 "type statements" are now "type declaration statements". 5.1.1 states "A type specifier specifies the type of all entities declared in an entity declaration list." Nowhere, though, is there a definition of "declaration". What does it mean, in Fortran 90, to "declare" something? ANSWER: The edits below add a definition of "declaration" and, for clarity, also add a definition of "specification". Edits related to these definitions are also provided. REFERENCES: EDITS: 1. Replace the text of 2.5.3 "Declaration" [16:13-18] with: A data object declaration specifies the creation, attributes, and lifetime of the object. Every data object must be declared. Declarations can be explicit or contextual. Data object attributes not specified explicitly are determined implicitly. A declaration of a data object of derived type is also a declaration of all of its components. In a scoping unit, if a name appears as: (1) an object-name in an entity-decl in a type-declaration, SAVE, POINTER, or TARGET statement (2) a named-constant in a named-constant-def in a PARAMETER statement (3) an array-name in a DIMENSION or ALLOCATABLE statement (4) a variable-name in a common-block-object in a COMMON statement (5) the name of a variable that is wholly or partially initialized in a DATA statement (6) the name of an object that is wholly or partially equivalenced in an EQUIVALENCE statement (7) a dummy-arg-name in a FUNCTION, SUBROUTINE, ENTRY or statement-function statement (8) a result-name in a FUNCTION or ENTRY statement then those statements constitute an explicit declaration of a data object with that name in that scoping unit. otherwise: if a name that is not a procedure name, module name, program name, generic identifier, common block name, namelist group name, construct name, or derived type name, appears in any statement and that name is not the name of a data object accessed by host or use association then those appearances constitute a contextual declaration of a data object with that name in that scoping unit 2. In section 5.2.9 "DATA statement", in the fifth constraint following R537 [52:31-32]: delete "made accessible by use or host association," as now redundant with the definitions of use and host association. 3. In 11.3.2 "USE statement", in the paragraph beginning "If two or more" in the third sentence [158:29-31]: change: through to: through explicit declaration, 4. In 12.1.2.2.1 "Host association" replace items 5 though 12 with the one new item [164:8-17] (5) An explicitly declared data object (2.5.3); 5. In Annex A, add to page 256 after "datum" [256:10+] Declaration(2.5.3): A declaration specifies the existence of a data object. 6. In Annex A, add to page 260 after "size" [260:14+] Specification: A specification assigns attributes and properties to names. SUBMITTED BY: Dick Weaver HISTORY: 92-232 Submitted 92-232r Draft response, withdrawn 93-144 m125 unanimous consent 93-255r1 m127 ballot failed 16-7 94-103 m128 revised response, approved uc 94-116 m129 X3J3 ballot failed 16-7 94-223 m130 revised response 94-335 m131 alternate response proposed, withdrawn -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Interpretation STATUS: X3J3 draft response 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 returns 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 either argument is zero sized the result is false. The edits in defect item 000027 clarify the intent. Answer 2a: The result is false because P1 and P2 each are zero sized. Answer 2b: The result is false because the arrays are of zero size. Discussion: The reasons for having the ASSOCIATED function return false for zero-sized arrays is based on an analogy with sharing storage and how assignment works. In normal English we understand the concept of "totally associated" and "partially associated". If two things are totally associated then doing something to one of them does the exact same thing to the other. If two things are partially associated then doing something to one of them does something to the other. Section 14.6.3.3 hints at this by discussing "totally associated" in terms of "the same storage sequence". After executing assignment statements like I = values J = different_values we would call I and J associated if it were no longer true that I == values. Zero-sized arrays are the end case where doing "something" to them is equivalent to doing nothing to them. And in the example above we would still have I == values after the assignment if both I and J were zero-sized but would otherwise appear to be associated. We could also conclude that after the pair of assignment statements above executed we would have I == different_values if I and J were zero sized, since the comparison operators return true for zero-sized objects. However, on balance it seems better to view the comparison with the initial conditions, not the potential changed conditions. As a practical matter sensible use of the ASSOCIATED function with zero-sized arrays will usually require user special casing of the results. EDITS: None. 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 94-160 m129 WG5 ballot, failed 94-253r3 m130 revised response, approved u.c. 94-306 m131 X3J3 ballot, approved 15-4 95-044 m132 WG5 ballot, approved, with Reid edit 95-306r1 m135 withdrew edits as defect item 27 supplies better edits, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 did not contain the following words at the end of the first paragraph of edit 2 "If such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent." The earlier answer also included different wording for the start of the second paragraph of edit 2: "If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript:" and did not include the paragraph: "If the dummy argument has the TARGET attribute and is an explicit-shape array or is an assumed-size array and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) On invocation of the procedure, whether any pointers associated with the actual argument become associated with the corresponding dummy argument is processor dependent. (2) When execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent." An earlier answer to this defect included different wording for the first paragraph of edit 3. "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript." An earlier answer to this defect included the edit: Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." The earlier versions of edits 2 and 3, along with edit 1 and the just mentioned deleted edit were included in corrigendum 2. EDITS: 1. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 2. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If such a dummy argument is associated with a dummy argument with the TARGET attribute, whether any pointers associated with the original actual argument become associated with the dummy argument with the TARGET attribute is processor dependent." If the dummy argument has the TARGET attribute and is either 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." 3. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute and is either 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 95-281 m135 revised edits after errors were discovered, WG5 approved (N1161) -------------------------------------------------------------------------------- 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: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 or use 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.1.2.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. A named constant can appear in a of a function statement if it is accessible within the function by host or use 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 for objects declared within the function. 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. 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." 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 95-281 m135 revised response, reworded edit 3, WG5 approved (N1161) -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: WG5 approved; ready for X3J3 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 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. Note that the program fragment in question 2 is standard conforming for a given processor only if that processor returns the value '2' or '1' in the SIZE argument when RANDOM_SEED is called. EDIT: In section 13.13.84 add the following text [228:13+] "The pseudorandom number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Computation of the seed from argument PUT is performed in a processor dependent manner. The value specified by PUT need not be the same as the value returned by GET in an immediately subsequent reference to RANDOM_SEED. For example, following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. When the values differ, the use of either value as the PUT argument in a subsequent call to RANDOM_SEED will result in the same sequence of pseudorandom numbers being generated. For example, after execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot failed 13-7 95-142r1 m133 revised response, approved 10-2 95-183 m134 X3J3 ballot failed 12-5 95-281 m135 revised edit, approved by WG5 (N1161) --------------------------------------------------------------------------------