From JANSHEP@torolab2.vnet.ibm.com Mon May 9 11:25:14 1994 Received: from vnet.ibm.com by dkuug.dk with SMTP id AA21790 (5.65c8/IDA-1.4.4j for ); Mon, 9 May 1994 21:26:40 +0200 Message-Id: <199405091926.AA21790@dkuug.dk> Received: from TOROLAB2 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 0390; Mon, 09 May 94 15:25:37 EDT Date: Mon, 9 May 94 15:25:14 EDT From: "Janice Shepherd" To: sc22wg5@dkuug.dk Subject: 006 items X-Charset: ASCII X-Char-Esc: 29 The following 16 interpretation items have status "X3J3 draft response". I will be sending out an X3J3 letter ballot on these 16 items. Non-X3J3 members are welcome to send in comments. Thanks. Janice C. Shepherd --------------------------------------------------- NUMBER: 00000d TITLE: Minor edits and corrections KEYWORDS: typographical errors DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: ANSWER: REFERENCE: EDITS: 10. Page 339, section D.2.3 [339:3], add after the line for "'" ' " R408 R409 R410 R420' Rationale: Terminal symbol " was omitted from list 11. Section 7.2.3., first sentence [85:2] Change "operator" to "operation". 12. Section 10.9.1.2., first sentence [152:23] After "" add "(10.9)" 13. Annex A, [255:42] Change "CASE" to "SELECT CASE" 14. Section C4.3 [266:17] Change "KIND" to "kind". 15. Section C10 [281:5] Change "an apostrophe edit descriptor" to "a character constant edit descriptor delimited with apostrophes" 16. Section C10 [281:6-7] Change "the apostrophe edit descriptor" twice to "the edit descriptor" Rationale: for 15 and 16: In section 10 the term "apostrophe edit descriptor" is absent (see 10.2.1 and 10.7.1) 17. Section C13.1.6.3 [294:39-42] Delete word: "Declared" (4 times) Rationale: In section 13 descriptions of these functions do not contain the word "declared". These array inquire functions allow certain properties of an array to be determined dynamically. SUBMITTED BY: HISTORY: 94-165 m129 submitted item 10, approved u.c. 94-161r2 m129 submitted items 11-17, approved u.c. ------------------------------------------------------------------------------- NUMBER: 000004 TITLE: Blanks in format specifications in free form source KEYWORDS: source form - free, i/o format specification, blanks DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following format specification valid in free form source? FORMAT (B N) ANSWER: Yes. Discussion: Sections of Fortran 90 are not consistent. 3.3.1: In free form, blank characters must not appear within lexical tokens other than in a character context. and A blank must be used to separate names, constants, or labels from adjacent keywords, names, constants, ... 10.1.1: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor. It can be seen that the text in chapter 3 does not consider edit descriptors. The text will be revised so that: -- blanks are allowed in edit descriptors. These changes are desirable because format specifications are conceptually their own sub-language, where the components thereof are not affected by the source form of the containing procedure and are not subject to most other syntactic rules. Thus, the rules concerning blanks in keywords do not apply to edit descriptors in format specifications. This treatment of format specifications is desirable so that "run-time formats" can be processed independently of the source form of the procedure containing a data transfer statement. In the absence of these changes, some standard conforming subprograms would not constitute a standard conforming Fortran 90 program, depending on which source form OTHER subprograms were written in. For example, consider a character variable containing a format specification which was passed to a subprogram where the variable was used in an I/O statement. In a standard conforming subprogram, this format specification could contain embedded blanks within an edit descriptor (i.e. "(B N, I5)"). If this variable is then passed to another subprogram, which uses it as a format in a data transfer statement, then the validity of the entire program would depend on which source form the called subprogram was written in. EDITS: 1. Section 3.3.1, second paragraph [22:6], change "... character context." to "... character context or in a format specification." SUBMITTED BY: J. T. Martin 119-JTM-2 (119.015) HISTORY: 119-JTM-2 119-RPK-1 X3J3/92-044 S20.120, number 4 X3J3/92-075 X3J3/92-145 Draft Interpretation by CIO, withdrawn Approved as X3J3/92-176 at m122 by uc X3J3/92-326 ballot comments (jw note) minutes m124 approved 15-2 X3J3/93-111 m125 ballot approved; accept Martin edits X3J3/94-160 m129 WG5 ballot, failed X3J3/94-174r2 m129 elaborated discussion, removed first and second edit; approved 21-0 ------------------------------------------------------------------------------ NUMBER: 000007 TITLE: Duplicate module procedures in interface blocks KEYWORDS: module procedure name, interface block, generic name DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: May a module procedure name be referenced on more than one MODULE PROCEDURE statement for a given generic name in a scoping unit, either in a single interface block or in multiple interface blocks specifying that generic name? Section 12.3.2.1 indicates: "A procedure must not have more than one explicit specific interface in a given scoping unit." ANSWER: No. Discussion: The standard routinely disallows such redundant specifications within a scoping unit. The prohibition for this case was inadvertently overlooked. This deficiency is remedied by the supplied edit. A MODULE PROCEDURE statement does not specify the explicit interfaces of the module procedure names, so the text referenced from 12.3.2.1 does not apply. Example: INTERFACE INT_1 MODULE PROCEDURE FOO, FOO ! second FOO is illegal MODULE PROCEDURE FOO1 MODULE PROCEDURE FOO1 ! FOO1 is illegal here END INTERFACE INT_1 INTERFACE INT_2 MODULE PROCEDURE FOO2A, FOO2B END INTERFACE INT_2 INTERFACE INT_2 MODULE PROCEDURE FOO2B, FOO2C ! FOO2B is illegal here END INTERFACE INT_2 REFERENCES: ISO/IEC 1539:1991(E) Section 12.3.2.1 EDIT: The following additional constraint should be added to section 12.3.2.1 [167:36]: Constraint: A in a must not be one which previously had been specified in any with the same generic identifier in this specification part. SUBMITTED BY: S. M. Lammers, 119-SML-1 (119.019) HISTORY: 120-MBSH-4A (120.096A) Original interpretation 92-039 Adopted because this interpretation is more consistent with requirements concerning duplication of other specification statements in a given scoping unit. 92-095 modification WG5/N786A Commented on, Victoria meeting, item marked 1167/36+. 92-155A m122 approved uc 94-034 m128 X3J3 ballot failed 25-3 94-093 m128 alternate answer proposed, approved uc 94-116 m129 X3J3 ballot failed 15-8 94-197r1 m129 revised discussion and edit, approved 15-1 ----------------------------------------------------------------------------- NUMBER: 000028 TITLE: Host association and Implicit type rules KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION 1: Consider the following program fragment: MODULE A CONTAINS SUBROUTINE B(Z) IMPLICIT INTEGER (X) 10 Z = XXX !Local variable or invalid function reference? ... END SUBROUTINE REAL FUNCTION XXX() ... END FUNCTION END MODULE In the above example in statement 10, is XXX an implicitly typed scalar variable or an erroneous function reference to module procedure XXX? That is to say, does the syntax of the reference determine which entity is referenced? QUESTION 2: Consider the following program fragment: MODULE X INTEGER, DIMENSION(10) :: A ... CONTAINS SUBROUTINE Y() ... CONTAINS SUBROUTINE Z(I) 20 A(I) = I ! Host associated array reference ! or invalid reference to function A? END SUBROUTINE FUNCTION A(K) ! Hides array A in module spec part? ... END FUNCTION END SUBROUTINE END MODULE Is the reference to A in statement 20 a reference to the array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER 1: The reference to XXX is an invalid reference to the host associated module procedure XXX. The syntax of the reference does not determine which entity is referenced. ANSWER 2: The reference to A is an invalid reference to the host associated internal procedure A. Discussion: Section 5.3, in the fourth paragraph beginning "Any data entity ...", defines which data entities are implicitly typed. This definition excludes variables made accessible by use association or host association. In the first example, a form of reference does not differentiate between a host associated entity and a local implicitly typed scalar. In the second example, within subroutine Y the definition of the internal procedure A makes the array A inaccessible by host association (section 12.1.2.2.1). The internal procedure A is accessible within subroutine Z by host association. The reference to A(I) in subroutine Z is an invalid reference to function A. REFERENCES: EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ui 105, ballot comments (jw note) 93-134 m125 unanimous consent 93-255r1 m127 ballot failed 23-1 93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, approved u.c 94-116 m129 X3J3 ballot failed 16-7 94-164 m129 clarify question and answer, 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: X3J3 draft response QUESTION: Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/ copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER: Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute, 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 actual argument has the TARGET attribute and the corresponding dummy argument has the TARGET attribute: (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 actual argument does not have the TARGET attribute and the corresponding dummy argument has the TARGET attribute, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG If (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 ----------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=-3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character" The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,- 1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. EDITS: (1) In section 7.1.6.1, in the second list, in item 2 [77:39], change the phrase: "either initialization expressions or implied-DO variables" to "initialization expressions" (2) In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" (3) In section 7.1.6.1, in the second list, in item 7 [78:11], change "." to ", or" (4) In section 7.1.6.1, in the second list, add item 8: "(8) An implied-DO variable where the bounds and strides of the corresponding implied-DO are initialization expressions." SUBMITTED BY: Janice C. Shepherd HISTORY: Submitted as paper 93-027 Draft response 93-088 approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. ------------------------------------------------------------------------------ NUMBER: 000138 TITLE: PRIVATE accessibility of a MODULE PROCEDURE KEYWORDS: PRIVATE attribute, module procedure DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: 4.4.1 "Derived Type Definition", fourth paragraph following the five constraints following R429 states If a type definition is private ... any procedure that has a dummy argument or function result that is of the type are accessible only within the module containing the definition. 5.2.3 "Accessibility Statements", third constraint, states A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility ... Noting that "accessible only within the module" is the definition of PRIVATE accessibility, it seems that the constraint requires the user to do something (specify the PRIVATE attribute) that is already specified as done per 4.4.1. Is the user required to specify PRIVATE accessibility for a module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility? ANSWER: Yes. The text in 4.4.1 is a general statement of the requirement. The text in 5.2.3 is a specific statement of the requirment. SUBMITTED BY: Dick Weaver EDITS: None HISTORY: 93-159 m125 submitted 94-208r1 m129 response; approved u.c. -------------------------------------------------------------------------------- NUMBER: 000142 TITLE: Namelist I/O KEYWORDS: i/o namelist, derived type, use association, PRIVATE attribute, use renaming DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION 1: Can a namelist group item be of derived type if the components of the derived type are inaccessible? Section 5.4 indicates that a namelist-group-name can't have the PUBLIC attribute if any of its items have the PRIVATE attribute. An object of derived type can have the PUBLIC attribute even if its components are private, so this text is insufficient. While Section 9.4.2 indicates that an input/output list item can not be of derived type if any of its components are not accessible, this section does not cover namelist list items. Here is an example of variables of derived type with private components appearing in namelist lists: Example 1: MODULE M TYPE T PRIVATE INTEGER I,J END TYPE TYPE (T) X NAMELIST /N1/ X END MODULE PROGRAM NN USE M TYPE (T) NX NAMELIST /N2/ NX END PROGRAM QUESTION 2: If a namelist group name or a namelist group item is accessed via use association and the USE statement supplies a rename of the group name or of the item, is it the original name that appears in the input/output record or the name introduced through renaming? Section 10.9.1 item (2) appears to indicate that for the group name it is that name that appears in the input statement that is used. Other references in sections of 10.9 do not appear to contain further details of which name to use. As renaming on USE statements is provided to limit name conflicts within the scope that has the USE statement, it appears that such renaming should not affect the names used in namelist I/O. Here is an example to consider: Example 2: MODULE M NAMELIST /N/ I, J INTEGER K END MODULE SUBROUTINE S() USE M , NN => N, JJ => J, KK => K CHARACTER J, K NAMELIST /X/ KK, K I = 1 JJ = 2 KK = 3 J = 'A' K = 'B' WRITE(10, NML=NN) WRITE(10, NML=X) END ANSWERS: 1. No. As with an input/output list, the components of any namelist group objects referenced in a namelist input/output statement which are of derived type must be accessible. An edit to clarify this is included. 2. Section 10.9.1 item (2), should indicate that the namelist group name used in the namelist input/output record is the namelist group name specified in the original namelist statement. This would be consistent with sections 10.9.1 and 10.9.2.2 which both state that the name used in the name value sequence is the name of the item from the namelist statement. In particular, the output of the supplied example (assuming that the DELIM= specifier has been assigned the value APOSTROPHE) is: &N I=1, J=2 / &X KK=3, K='B'/ An edit is provided to correct section 10.9.1 EDITS: 1. In section 5.4, add to the end of the second constraint [56:13] "or have private components" 2. In section 10.9.1, replace item (2) with [151:39-40] "The character & followed immediately by the as specified in the namelist statement," SUBMITTED BY: Janice C. Shepherd HISTORY: X3J3/93-189 submitted X3J3/93-218 m126 proposed response approved 13-1 X3J3/93-255r1 m127 ballot failed 21-3 X3J3/93-299r1 m127 withdrawn X3J3/94-067 m128 clarified answer 2 and added new edit. Approved uc, but then returned to status "X3J3 consideration" as meeting 127 ballot not completely addressed. X3J3/94-178 m129 altered first edit, approved u.c. ------------------------------------------------------------------------------ NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (p228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor- dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) This is processor dependent. The standard states: "If no argument is present, the processor sets the seed to a processor dependent value." [228:13] This leaves the value of the seed and the method of generating that value up to the processor. Therefore, the standards committee cannot rule on whether X = Y or not. Different processors will handle this in different ways. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDITS In the description of RANDOM_SEED after RANDOM_NUMBER, add the text : [228:2] "The pseudo random number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) it is not required that SEED1 equal SEED2. However it is required that calls to RANDOM_NUMBER immediately after a call to RANDOM_SEED with a seed that is either SEED1 or SEED2 return the same sequence of pseudo random numbers. In particular, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) it is required that X1=X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. ------------------------------------------------------------------------------ NUMBER: 000159 TITLE: May undefined expressions be used as arguments to INQUIRY functions KEYWORDS: inquiry functions DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 13.7.2 Numeric inquiry functions contains the phrase "The value of the arguments to these functions need not be defined", and section 13.8.5 Array inquiry functions contains the similar phrase "The values of the array arguments to these functions need not be defined" One intent is to allow inquiries about the "static" properties of variables, for example: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA)) CHARACTER*(DIGITS(AA)) CC ... where the properties of BB and CC don't depend on the numerical values of AA. However, since the arguments to functions can also be expressions, may the expressions be undefined in the more traditional sense of not having a defined result value? Consider programs like: PROGRAM EXAMPL PARAMETER (N=3) REAL AA(N,N,N,N) REAL BB(SIZE(AA + 1.0)) CHARACTER*(DIGITS(AA + 1.0)) CC ... where the expression "AA + 1.0" is undefined in the normal sense of the word since AA is undefined. Must a processor accept programs where actual argument expressions (involving one or more operators or functions references, as opposed to expressions consisting of a single variable reference) would, if evaluated, use undefined variables or produce undefined results? ANSWER: No, the committee's intent was only to include inquiries about the attributes of undefined variables in the set of allowed inquiries. Discussion: That the resulting text applies to all expressions was unintended and edits are provided to correct this. Note that 'variable name' does not permit substrings or section-subscripts. Edits are not provided for the PRESENT or ASSOCIATED inquiry functions; neither of these permit expressions as arguments. EDITS: 1. In section 13.5.4 Character Inquiry Function [184:18-19] replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined." 2. In section 13.5.7 Bit Manipulation and Inquiry Procedures [185:4-5] In the paragraph beginning "An inquiry ..." replace the second sentence "The value of ...." with "If the argument to this function consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined, if a pointer it may be disassociated, and if allocatable need not be allocated." 3. In section 13.7.2 Numeric Inquiry Functions [186:7-8] replace the last sentence "The value of ...." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined, if a pointer it may be disassociated, and if allocatable need not be allocated." 4. In section 13.8.5 Array Inquiry Functions [187:12] replace the second paragraph "The values of ..." with "If the argument to these functions consists of a single primary (7.1.1.1) that is a variable name then that variable need not be defined." SUBMITTED BY: Dick Hendrickson HISTORY: 93-279 m127 submitted 94-017 m128 proposed response 94-206 m129 vote on response in 94-017, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000162 TITLE: Pointer expression "(i)" KEYWORDS: expression - pointer, pointer DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Given the specifications INTEGER, POINTER :: I, J INTEGER :: K 1. Are the following statements equivalent? J => I J => (I) 2. Are the following statements equivalent? K = I K = (I) ANSWER: 1. No, the statements are not equivalent. Further, even assuming "I" has become pointer associated by statements not shown, the second pointer assignment is not standard conforming. 2. Yes, it is intended that the statements be equivalent; an edit is provided to clarify this intent. Discussion: 1. Data objects may have attributes, including the POINTER attribute (first paragraph of section 5). In addition, function references may "deliver a pointer result" (section 7.5.2 and 12.5.2.2). "(I)" is an expression containing a primary, "(I)", that is not a , a , or a subobject of a constant, therefore "(I)" is not a data object. As "(I)" is not a data object nor a function result, is cannot be a pointer. Section 7.5.2 defines two different semantics for pointer assignment, depending upon whether the is a pointer, so the statements are not equivalent. Section 7.5.2. states that must be a variable with the TARGET attribute, a subobject of a variable with the TARGET attribute, a variable with the POINTER attribute, or an expression delivering a pointer result. "(I)" is none of these, so the second pointer assignment is not standard conforming. 2. Section 7.1.4.1 states: "If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced." "(I)" does not involve an intrinsic operation nor a defined operation, so the exact treatment of the pointer object is not fully specified. Edits are provided to include this example in the quoted language from section 7.1.4.1. With the edits, the "I" contained in "(I)" references the target object, as does "(I)". Thus, in the assignment statement "K=I", "I" references the target of "I", as does "K=(I)", so the statements are equivalent. EDIT: 7.1.4.1: Change the first sentence of the last paragraph to: [78:18-19] "If a pointer appears as one of the following, the associated target object is referenced: (1) A primary in an intrinsic operation, (2) A defined operation in which it corresponds to a nonpointer dummy argument, (3) As the of a parenthesized primary, or (4) As the only primary on the right hand side of an intrinsic assignment statement." SUBMITTED BY: Dick Weaver HISTORY: 93-280 m127 submitted 94-198r1 m129 response approved 17-4 -------------------------------------------------------------------------------- NUMBER: 000165 TITLE: Vector subscripts in Namelist input KEYWORDS: vector subscript, i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Can a namelist input record include vector subscripts? Section 10.9.1.1 indicates that if a namelist group object is an array then the input record can include a subobject of that array. ANSWER: No, vector subscripts are not allowed in a namelist input record. An edit to clarify this is included. Discussion: One commentor on a letter ballot noted that section 10.9.1.1 [8:9] states: "Subscripts, strides, and substring range expressions used to qualify group object names must be optionally signed integer literal constants". The commentor then concluded that since a vector subscript is not a literal constant, it is not allowed. Unfortunately, a vector subscript is not a , so additional edits are required. EDIT(S): In section 10.9.1, second paragraph [152:4], add the following sentence at the end of the paragraph: 'The optional qualification, if any, must not contain a vector subscript.' SUBMITTED BY: Janice C. Shepherd HISTORY: 93-285 m127 submitted 93-311r1 m127 response approved uc 94-034 m128 X3J3 ballot failed 18-10 94-015 m128 proposed changing meaning of 'subscript' in f95 94-195r1 m129 added discussion and revised edit, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000169 TITLE: End of Namelist Input KEYWORDS: i/o namelist DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: What is supposed to be printed by the following? NAMELIST /NNN/ I, J INTEGER :: A(2) = 1 READ (*,NML=NNN) or NAMELIST /QQQ/ A PRINT *, I READ (*,NML=QQQ) END PRINT *,A(2); END if the input file is: &NNN I=1, J=2, &QQQ A(1)=2, I=3/ A(2)=3/ The following set of quotes from the standard leads me to believe the answer is 1, which at least is surprising and possibly not intended. Section 9.4.6 [128:22-29]: "Termination of an input/output data transfer statement occurs when any of the following conditions are met: . . . (3) Name... input reaches the end of a record after having processed a name-value subsequence for every item in the namelist-group- object-list." In the example above, after reading I=1 and J=2, condition (3) appears to be satisfied and when the end of the record (line) is reached, the I/O should terminate. A possible reaction to this is that "record" should mean everything up to and including the "/", but a) that is NOT the definition of record generally given, and b) in section 10.9.1 [152:1], item (5) it states that "A slash to terminate the namelist input statement." This is very peculiar use of the term "statement", which does not correspond to the usage elsewhere in the standard, but I must assume that this word was used deliberately because the word "record" is not correct (being a "line"). The other thing to consider is the position of the file after completion of the READ statement. The standard states (last sentence of 9.2.1.3.3) it should be at the end of the current record, which means that if you do another READ, you would read the line "I=3/". A slight bit of evidence that all this was not intended appears in the sentence in section 10.9.1.2 [152:47-48]. "Successive namelist records are read by namelist input until a slash is encountered; ..." (10.9.1.2 Namelist Input values) or perhaps this sentence is missing the exception listed in section 9.4.6 "Termination of data transfer statements" [128:22-29]. ANSWER: The intent of the standard was that namelist input should proceed until it reaches the terminal "/" as indicated by item 6 in section 9.4.6, unless items 4 or 5 apply. Corrections to the standard are provided. Discussion: The sentence in section 9.4.6 item 3 [128:27-28] is wrong. For namelist input, the input data transfer statement is terminated when the terminating "/" is encountered, as discussed by item 6 in the same section. EDIT(S): In section 9.4.6, item 3 [128:27-29] delete "or namelist input reaches the end of a record after having processed a name-value subsequence for every item in the " SUBMITTED BY: Janice C. Shepherd (for Walt Brainerd) HISTORY: 93-284 m127 submitted 93-313 m127 response approved uc 94-034 m128 X3J3 ballot failed 26-1 94-203 m129 clarified answer, approved 19-1 -------------------------------------------------------------------------------- NUMBER: 000174 TITLE: Consistent definition of NCOPIES KEYWORDS: REPEAT intrinsic, SPREAD intrinsic, NCOPIES DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following two function references: REPEAT (... NCOPIES=N) SPREAD (... NCOPIES=N) Based on the definitions of REPEAT in section 13.13.87 and SPREAD in section 13.13.101, the following observations can be made. When N has a positive value: REPEAT returns the concatenation of NCOPIES of a string SPREAD returns an array, broadcasting NCOPIES of a source along a dimension When N has the value 0: REPEAT returns a zero-length string SPREAD returns a zero-sized array But, when N has the value -1, something different happens REPEAT is invalid. For repeat NCOPIES must not be negative SPREAD returns a zero-sized array. The definition of SPREAD references NCOPIES with MAX(NCOPIES,0) Thus, while uses of NCOPIES have a consistent model for both positive and zero values, the negative (out-of-range) case has introduced what would appear to be capricious differences, one an error while the other is ignored and treated as zero, thus complicating the language and astonishing the user. Should NCOPIES have a consistent definition for negative values? ANSWER: No. Discussion: As the use of NCOPIES in SPREAD is for a subscript then the returning of a zero-sized array for negative values of NCOPIES is consistent with the treatment of negative extents in array sections. Within REPEAT NCOPIES is not used as the subscript of an array. EDITS: none SUBMITTED BY: Dick Weaver HISTORY: 94-133 m129 submitted, response supplied failed 9-14 94-133r3 m129 revised answer and deleted edits; approved 19-1. -------------------------------------------------------------------------------- NUMBER: 000176 TITLE: Definition of RANDOM_SEED KEYWORDS: RANDOM_SEED intrinsic DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: The definition in 13.13.84, RANDOM_SEED, for the optional argument GET is: must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is set by the processor to the current value of the seed. There is similar text for the PUT argument. For both cases -- "set" is used in a manner that appears to specify assignment. For similar uses of "set" see DATE_AND_TIME, IBSET, and SET_EXPONENT. -- "current value" is not the same thing as "physical representation". Setting, or assignment, of a value and necessary conversions, are described in section 7.5. "physical representation", however, was more likely intended for RANDOM_SEED. -- The shape of the seed is processor dependent and the specification for both GET and PUT results in different semantics depending on whether the processor's seed is an array of default integers, an array of some other numeric type, or a scalar. Further, the descriptions of PUT "set the seed value" and GET "set ... to the current value of the seed" would appear to specify that: -- the processor must accept whatever is specified for a seed value when some values, 0 for example, are often not suitable -- PUT and GET can be used for global communication; assigning a value with PUT and later retrieving that same value with GET. 1. Is the following what was intended for GET? must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. Denoting this array by "a" and the current value of the seed by "s", TRANSFER (SOURCE=s, MOLD=a) is assigned to "a". TRANSFER hides both type and shape, assigning not the current value of the seed but the physical representation of that value independent of shape. Thus the seed can be of any type and any shape. Alternately must be a default integer array of rank one and size >= N. It is an INTENT(OUT) argument. It is assigned the physical representation of the seed value in a processor dependent manner. 2. PUT semantics are more complicated in that the argument specified for PUT may not always be suitable as a seed. Thus while the assignment semantics currently specified may not have been intended, neither is it appropriate to specify TRANSFER semantics. Are PUT semantics processor dependent? This would allow processor seeds of any type and shape. 3. Given a value specified for PUT, can processors alter that value for use as a seed? ANSWER: 1. Yes, for GET "TRANSFER" semantics were intended, however "processor dependent" is both more general and parallels the PUT edit. 2. Yes, specifying PUT semantics as processor-dependent is correct. 3. Yes, the value supplied by PUT may be altered in constructing a seed. Edits are provided. EDIT: 1. In 13.13.84, RANDOM_SEED, PUT argument, replace the last sentence (beginning "It is used by the processor ..." with [228:9]: It is used in a processor-dependent manner to compute the seed value. It is not required that an immediately following "CALL RANDOM_SEED (GET=aseed)" assign a physical representation to "aseed" identical to the physical representation of the value specified for PUT. 2. In 13.13.84, RANDOM_SEED, GET argument, replace the last sentence (beginning "It is set by the processor ...") with [228:11-12]: It is assigned the physical representation of the seed value in a processor-dependent manner. SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000178 TITLE: Specific routine with same name as generic passed as argument KEYWORDS: argument - actual, specific name DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: If a generic interface contains a specific interface with the same name as the generic, can the procedure with the specific name be passed as an actual argument? The penultimate constraint in 12.4.1 states [172:7-8]: "A must not be the name of an internal procedure or of a statement function and must not be the generic name of a procedure (12.3.2.1, 13.1)." On the other hand, 12.4.1.2 states [173:33-34]: "If the specific name is also a generic name, only the specific procedure is associated with the dummy argument." These two statements appear to conflict. ANSWER: Yes. As indicated by 12.4.1.2, a specific procedure may appear as an actual argument even if it has the same name as a generic name. Discussion: The penultimate constraint of section 12.4.1 should have restricted a generic name from appearing as an actual argument when the generic name is not also a specific name. The constraint should not have restricted the appearance as an actual argument of a specific name that is also a generic name. As indicated by the referenced text from section 12.4.1.2, the latter case is permitted by the standard. An edit is provided to correct the constraint. The following program fragment is standard conforming SUBROUTINE TEST INTERFACE F FUNCTION F(X) REAL F, X END FUNCTION F END INTERFACE CALL THING (F) ! F is specific as well as generic END SUBROUTINE TEST REFERENCES: JOR item 50 EDIT: Section 12.4.1, insert the following in the penultimate constraint, ahead of "(12.3.2.1, 13.1)" [172:8]: "unless it is also a specific name" SUBMITTED BY: Janice C. Shepherd HISTORY: 94-157 m129 submitted with proposed response, approved u.c. THE END.