From janshep@watson.ibm.com Tue Jun 13 11:38:25 1995 Received: from watson.ibm.com by dkuug.dk with SMTP id AA28823 (5.65c8/IDA-1.4.4j for ); Tue, 13 Jun 1995 21:43:23 +0200 Message-Id: <199506131943.AA28823@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7793; Tue, 13 Jun 95 15:42:09 EDT Date: Tue, 13 Jun 95 15:38:25 EDT From: "J.C. Shepherd" X-Addr: Research, Yorktown To: sc22wg5@dkuug.dk Subject: 006 items X-Charset: ASCII X-Char-Esc: 29 The following 006 items were approved at X3J3 meeting 133. These defect items will be part of an X3J3 email letter ballot. Thanks. Janice C. Shepherd -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Erratum STATUS: X3J3 draft response (to be put in the 008) QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: Although X3J3 agrees with the concept of the proposed change, the committee feels that the changes required will be more pervasive than simply changing the phrases cited in the Question. Due to the late stage of processing of the draft Fortran 95 standard, the committee believes that it will not have time to adequately address these changes for inclusion in the Fortran 95 standard. Therefore, we are adding the suggested changes to a committee standing document entitled "Editorial Considerations for 9x Draft Revision X3J3/008". (Note that although the name of the document needs to be updated, the document continues to exist as a standing document to be used in the preparation of the Fortran 2000 draft standard.) EDITS: The following edits will NOT be applied to the Fortran 95 draft standard. They exist in this document so that this document can be added to the 008 without loss of the work that was begun to apply the general changes noted in the Question. 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. Note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D 95-162 m133 Response revised to state the suggestions will be added to X3J3 standing document 008, passed u.c. -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following program fragment: MODULE ABC INTEGER G END MODULE PROGRAM MAIN USE ABC ! Contains name ABC REAL ABC ! Contains name ABC END PROGRAM Question 1: Is a module a global entity? Question 2: In the above program fragment, the name ABC in the main program is both the name of a module and of a local entity (of class (1)). May a local entity of class (1) in a scoping unit have the same name as a module accessed by that scoping unit? Question 3: May a module be accessed in a scoping unit that also accesses a local name that has the same name as the module? Specifically, in the example below can subroutine SUB reference the variable ABC? MODULE ABC INTEGER G END MODULE PROGRAM MAIN REAL ABC ! Contains name ABC ... CONTAINS SUBROUTINE SUB USE ABC ! Contains name ABC ... END SUBROUTINE END PROGRAM ANSWER: Answer 1: Yes, a module is a global entity. Answer 2: No, a local entity of class (1) in a scoping unit must not have the same name as a module accessed by that scoping unit. Answer 3: No, a module can not be referenced in a USE statement in a scoping unit that also accesses a local name that has the same name as the module. Variable ABC is not accessible by that name in the subroutine SUB. Discussion: Discussion for Answer 1: The second sentence of Section 11 states that a module is a program unit. Section 14.1.1 defines global entities. The definition includes modules because the definition lists program units. In addition, the response to Defect Item 90 clarified the fact that a module name is a global name by changing the following text in 12.1.2.2.1 [163:39-164:1] from A name that appears in the scoping unit as an in an is a global name... to A name that is declared to be an external procedure name (by an or an ), or that appears as a in a is a global name... Discussion for Answer 2: Answer 1 established that a module is a global entity and that a module name is a global name. Section 14.1.2 states ... a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit. Discussion for Answer 3: There are two general cases where a local name could conflict with a module name. The first is as follows where the local name is contained in the module itself: MODULE ABC REAL ABC END MODULE and the second is as in the specific example provided above in Question 3. Section 11.3 [157:24-26] states: The module name is global to the executable program, and must not be the same as the name of any other program unit, external procedure, or common block in the executable program, nor be the same as any local name in the module. This means that the first case is not standard conforming. Section 14.1.2 [241:29-31] states: Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit. The original description of host association in 12.1.2.2.1 inadvertently failed to account for module names. The response to Defect Item 90 supplies edits to rectify the omission. With those edits, 12.1.2.2.1 now clearly states that the appearance of a name as the in a prevents access by host association to an entity of the same name in the host scoping unit. EDIT: None SUBMITTED BY: Larry Rolison in X3J3/93-037 at m124. HISTORY: 93-037 m124 Submitted 93-097 m124 Draft response failed 93-148 m125 Revised response, withdrawn 93-235 m126 Revised response based on edit in item 82. approved uc 93-255r1 m127 ballot passed 24-0 HOLD per 82 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot failed HOLD per 90 95-139 m133 Revised response based on edits in Defect Item 127, draft response approved uc -------------------------------------------------------------------------------- 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 (page 228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor-dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) No, it is not the intent of the standard that X must equal Y after the example calls to RANDOM_SEED and RANDOM_NUMBER. The standard states: If no argument is present, the processor sets the seed to a processor dependent value. in 13.13.84. This leaves the value of the seed and the method of generating that value up to the processor. Therefore, the answer to the second question is no, it is not the intent of the standard that the same processor-dependent value be set into the seed on all such argumentless calls to RANDOM_SEED. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDIT: In section 13.13.84 add the following text [228:13+] "The pseudorandom number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Computation of the seed from argument PUT and of argument GET from the seed is performed in a processor dependent manner. The value specified by PUT may not be the same as the value returned by GET. For example, following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. If the GET argument corresponding to PUT argument P is used as the PUT argument in a subsequent call to RANDOM_SEED the sequence of pseudorandom numbers generated will be the same as for P. For example, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot failed 13-7 95-142r1 m133 revised response, approved 10-2 -------------------------------------------------------------------------------- NUMBER: 000158 TITLE: Leftmost (on a line) negative integer KEYWORDS: integer - negative, negative integer, conformance DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: In many computers today the range of values for integer types is not symmetric. Consider, for example, a machine with 8-bit integer arithmetic (to keep the numbers small). The integer range would typically be -128 to +127 Given an implementation that specifies an integer type with that range, do the following statements conform to Fortran 90? DATA I /-128/ I = - 128 ANSWER: The data statement is NOT VALID. r530 is ... / / r532 is ... r533 is ... r403 is [] Thus the - is the and 128 is an , but is out of range and, therefore, the statement is not valid." The assignment statement is NOT VALID. r735 is = following the expr syntax, we eventually find r710 is ... - r701 is r305 is ... r306 is Thus the - is an operator, 128 is an , but is out of range and, therefore, the statement is not valid. Constraining of constants to the range of values is described in 4.0. "Intrinsic data types are parameterized. In this case the set of values is constrained by the value of the parameter ..." and "An example ... is the integer data type. This data type has a processor-dependent set of integer numeric values, each of which is denoted by ..." A program is not standard-conforming if it contains references to integers that are outside the range specified by the processor (1.4). While a standard-conforming processor must detect the use of kind type parameters not supported by the processor, it need not detect the use of integers outside the range of a supported kind. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-277 m127 submitted 94-329r1 m131 response, approved 16-1 95-034r1 m132 X3J3 ballot failed 19-1 95-141 m133 revised response approved u.c. -------------------------------------------------------------------------------- NUMBER: 000173 TITLE: Definition of elemental intrinsic subroutine KEYWORDS: intrinsic, elemental subroutine, MVBITS DEFECT TYPE: Erratum STATUS: X3J3 draft response Section 13.2.2 defines an elemental subroutine as one that is specified for scalar arguments but may be applied to array arguments. MVBITS, 13.13.74 for example, is identified as an elemental subroutine. Section 13.2.2 asserts that, in the case of array arguments, the results are the same as would be obtained if the subroutine were applied separately to corresponding elements of each array. This assertion is true only if the input and output arguments do not overlap but there does not appear to be such a requirement. Question 1: For elemental intrinsic subroutines, is a requirement or constraint along the lines of "input and output arguments must not be associated" missing? Question 2: Alternately, should the text about "same results" be deleted and semantics added to these subroutines similar to those for assignment? ANSWER 1: Yes. A restriction similar to the suggested restriction is missing. ANSWER 2: No. The committee decided this imposed too great a burden on Fortran processors for the functionality provided. Discussion: The text in 13.13.74 which describes the "TO" argument specifically allows FROM and TO to be the same variable (which includes s). The standard should have prohibited the FROM and TO arguments from being associated in any other way, including partial overlaps. The TO argument should also be prohibited from being associated with any other argument to MVBITS. The other intrinsic subroutines should have had similar restrictions also. EDIT: Add the following sentence to the end of section 13.2.2 [183:35]: "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an intrinsic subroutine must satisfy the restrictions of 12.5.2.9. SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted 95-023r1 m132 draft response, approved u.c. 95-023r1 m132 X3J3 letter ballot, failed 10-8 95-144 m133 revised response, approved u.c. -------------------------------------------------------------------------------- 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 provided in defect item 000148 describe the operation of RANDOM_SEED and RANDOM_NUMBER. Edits to the description of RANDOM_SEED arguments PUT and GET are provided here. 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 accessed by the pseudorandom number generator." 2. In 13.13.84, RANDOM_SEED, GET argument, replace the last sentence (beginning "It is set by the processor . . .") with [228:12]: "It is set to the current value of the seed in a processor dependent manner." SUBMITTED BY: Dick Weaver HISTORY: 94-142r1 m129 submitted, approved u.c. 94-221 m130 X3J3 ballot, failed 21-2 94-324r1 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot, approved 19-1 HOLD for defect item 000148 95-155 m133 revised response, approved 12-1 -------------------------------------------------------------------------------- NUMBER: 000186 TITLE: Allowed values of POSITION= and STATUS= specifiers when changing BLANK= KEYWORDS: OPEN statement, POSITION= specifier, STATUS= specifier DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION 1:What values are allowed for the POSITION= specifier when an OPEN is used to "reopen" a file and change the BLANK= etc, specifiers? Section 9.3.4, page 115, lines 20+ states: "If the file to be connected to the unit is the same as the file to which the unit is connected, only the BLANK=, DELIM=, PAD=, ERR=, and IOSTAT= specifiers may have values different from those currently in effect..." QUESTION 2:What is the current value of the POSITION= specifier? QUESTION 3:Given a sequence like: OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "ZERO", POSITION="REWIND") WRITE(10 .......... are the following OPEN statements standard conforming? (Note that POSITION="ASIS" is the default for the OPEN) 1 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="REWIND") 2 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL" ) 3 OPEN( UNIT = 10, FILE = "TAPE10", BLANK = "NULL", POSITION="ASIS") A simple reading of the sentence is that 1 and 2 are standard conforming and have the same effect, but that 3 is not. The surprising feature is that execution of 1 does NOT rewind the file and that attempting to explicitly leave the file ASIS via 3 is nonstandard. It's not completely obvious that 2 is standard conforming. Section 9.3.4, page 115, line 23 states the OPEN "...does not cause any change in any of the unspecified specifiers..." so this apparently means that the POSITION= specifier is still "REWIND". However, section 9.3.4.7, page 117, line 25 states that the default value for the position specifier is "ASIS". QUESTION 4:Does the OPEN "not cause any change" from the initial specification of an unspecified specifier or does it use the default for an unspecified specifier? QUESTION 5:There is a set of similar questions for STATUS. If the STATUS= is omitted on the reopen, it defaults to "UNKNOWN". Section 9.3.4.2, page 116, lines 22+ appears to allow, for example, STATUS="NEW" on the initial OPEN but then requires either STATUS="OLD" or no STATUS= on subsequent reopens. Is this correct? ANSWER:In the following answers and discussion, the following terms are used: reOPEN (reOPEN-ing, reOPEN-ed): This is used to describe an OPEN statement for a unit which is already connected to the same file. This also applies to an OPEN statement for an external unit when the FILE= specifier is absent and the unit is already connected. properties of a connection: This is used to describe properties of a connection to an external unit that may be specified in an OPEN statement, including STATUS= and POSITION=. Note that the standard defines what the POSITION property is, but not what the STATUS property is. However, the standard does describe how the status changes during the process of an open, i.e. when STATUS="NEW" is specified, the file is created and the status changes to "OLD". Both POSITION and STATUS have a "current value", that is not necessarily the "value" specified in the OPEN statement. ANSWER 1:The standard is not clear about what values are legal for the POSITION= specifier when a file is "reOPEN-ed". The intent was to always permit a POSITION= specifier with a value of "ASIS", and to permit a value of "REWIND" only if the file was currently positioned at its initial point, and a value of "APPEND" only if the file was currently positioned at its terminal point. The edits below clarify what is allowed. ANSWER 2:The phrasing of the indicated paragraph is misleading. What the committee intended to say was that, except for the specifiers specifically listed, a specifier may not have a value different from those currently in effect, or in the case of the POSITION= specifier, the value must not specify a different position than the current position of the file. ANSWER 3:With the edits to the standard below, the OPEN statements labeled "2" and "3" are standard conforming for the indicated example (an OPEN followed by a WRITE followed by another OPEN, all for the same unit). The OPEN statement labeled "1" is not standard conforming in this example. ANSWER 4: The OPEN specifiers which are not specified when a file is reOPENed do not act as if the "default" value was specified for those specifiers. Instead, the property of the connection associated with that specifier is not changed by the reOPEN statement. This is described in the 6th paragraph of section 9.3.4, and this overrides the more general discussion of specifiers and their default values later in this chapter. ANSWER 5: Yes. Edits are provided to clarify what values are acceptable for the STATUS= specifier when reopening a file. Discussion: It is not absolutely clear in the Fortran 90 standard exactly what values are allowed for the POSITION= and STATUS= specifiers when a file is reOPENed. The standard is not clear what the phrase "currently in effect" in the sixth paragraph of section 9.3.4 means for the POSITION= and STATUS= specifiers. The committee intended that the phrase "currently in effect" mean the property of the connection at the time of the reOPEN, not the value of the specifier in the original OPEN statement. The language used in the standard in this area was adapted from the FORTRAN 77 standard, but some additional complications introduced by some new OPEN specifiers were not adequately addressed. When an OPEN statement is reOPENing a file, the POSITION= specifier with a value of "ASIS" is always allowed. When the file is positioned at its initial point, a reOPEN statement may have a POSITION= specifier with a value of "REWIND", and if the file is positioned at its terminal point a POSITION= specifier may have a value of "APPEND". The committee believes the standard already states this, using the intended interpretation of the phrase "currently in effect" in the 6th paragraph of section 9.3.4. An edit is included below to clarify this intent. The committee originally intended that if a STATUS= specifier was present when unit was reOPENed, the value for the STATUS= specifier should not conflict with the "current" value in effect; however, it is very difficult to discern from the text currently in the standard what is allowed and what is prohibited. Edits are provided to clarify what values may be specified for STATUS= when reopening a file. The edits below clarify what may be specified for the POSITION= and STATUS= specifiers when reOPENing a file. EDITS: 1.In section 9.3.4, sixth paragraph [115:22], change "currently in effect." to the following: "currently in effect. If the POSITION= specifier is present in such an OPEN statement, the value specified must not disagree with the current position of the file. If the STATUS= specifier is included in such an OPEN statement, it must be specified with a value of "OLD". 2.In section 9.3.4, add the following paragraph (note) after the 6th paragraph: [115:25+] "Note that a STATUS= specifier with a value of "OLD" is always allowed when the file to be connected to the unit is the same as the file to which the unit is connected. In this case, if the status of the file was "SCRATCH" before execution of the OPEN statement, the file will still be deleted when the unit is closed, and the file is still considered to have a status of "SCRATCH". 3.In section 9.3.4 [116:3], delete "OLD" and add the following sentence [116:3+]: "If the STATUS= specifier has the value OLD, the FILE= specifier must be present unless the unit is currently connected and the file connected to the unit exists." SUBMITTED BY: Dick Hendrickson for meeting 131 HISTORY: 94-297r1 m131 submitted 95-016 m132 draft response, 95-017r1 m132 draft response, approved u.c. 95-017r1 m132 X3J3 letter ballot, failed 17-1 95-160 m133 revised response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000193 TITLE: Pointer actual arguments with the OPTIONAL attribute KEYWORDS: TYPE: Erratum STATUS: X3J3 draft response QUESTION : Section 12.5.2.8 states the following about an optional dummy argument that is not present (as modified by Corrigendum 1): [179:39-40] "Except as noted in (5) above, it may be supplied as an actual argument corresponding to an optional dummy argument." Section 7.1.4.1 states (as modified by Corrigendum 2) : [76:20:22] "If the pointer is not associated with a target, it may appear as a primary only as an actual argument in a reference to a procedure whose corresponding dummy argument is declared to be a pointer, or as the target in a pointer assignment statement." Consider the following example : PROGRAM MAIN CALL INNER() CONTAINS SUBROUTINE INNER(PARG) OPTIONAL :: PARG POINTER :: PARG INTERFACE SUBROUTINE SUB(TARG) OPTIONAL :: TARG END SUBROUTINE END INTERFACE CALL SUB(PARG) END SUBROUTINE END PROGRAM In this example, PARG is an optional dummy argument that is not present and it is being supplied as an actual argument corresponding to an optional dummy argument. On the other hand, PARG is a pointer that is not associated with a target, therefore it should not be supplied as the actual argument corresponding to a dummy argument that is not a pointer. If a pointer dummy argument is not present, may it be specified as the actual argument corresponding to a dummy argument that is not a pointer? ANSWER : No. An optional dummy argument that is a pointer and is not present must not be supplied as an actual argument corresponding to a dummy argument that is not a pointer. This restriction should have been included in the list within section 12.5.2.8 Edits are supplied to correct this omission. EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" SUBMITTED BY: Janice C. Shepherd HISTORY: 95-097 m133 submitted, with proposed response 95-097 m133 approved, u.c.