From bleikamp@mozart.convex.com Wed Feb 1 02:02:47 1995 Received: from convex.convex.com by dkuug.dk with SMTP id AA21896 (5.65c8/IDA-1.4.4j for ); Wed, 1 Feb 1995 15:06:52 +0100 Received: from mozart.convex.com by convex.convex.com (8.6.4.2/1.35) id IAA27772; Wed, 1 Feb 1995 08:06:37 -0600 Received: from localhost by mozart.convex.com (8.6.4/1.28) id IAA19567; Wed, 1 Feb 1995 08:02:48 -0600 From: bleikamp@mozart.convex.com (Richard Bleikamp) Message-Id: <199502011402.IAA19567@mozart.convex.com> Subject: text for 006 items in X3J3 letter ballot To: sc22wg5@dkuug.dk (sc22wg5@dkuug.dk) Date: Wed, 1 Feb 95 8:02:47 CST X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Here are the 9 items that will be in the X3J3 006 letter ballot (from X3J3 meeting 132). While this is an X3J3 letter ballot comments from non-X3J3 members are also welcome. The ballot itself will follow shortly. Rich Bleikamp bleikamp@convex.com (214) 497-4133 -------------------------------------------------------------------------------- NUMBER: 000091 TITLE: Constraint diagnosis for PRIVATE attribute KEYWORDS: PRIVATE attribute, modules, constraints DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Must the violation of constraints be diagnosed when the criteria for the constraint is violated or confirmed across module definitions? More specifically should the following two constraints: The third constraint following R522: [49:26-28] A module procedure that has a dummy argument or function result of a type that has PRIVATE accessibility must have PRIVATE accessibility and must not have a generic identifier that has PUBLIC accessibility. The fourth constraint following R424: [33:10-11] If a component of a derived type is of a type declared to be private, either the derived type definition must contain the PRIVATE statement or the derived type must be private. be diagnosed in the following program?: MODULE A TYPE X INTEGER :: I END TYPE X TYPE Y TYPE (X) :: R ! Note component of type X END TYPE Y CONTAINS FUNCTION F() ! Module function of type X TYPE(X) :: F END FUNCTION F END MODULE A MODULE B USE A PRIVATE :: X ! Does the type Y now have a PRIVATE component? ! Does the function F now have a PRIVATE type? END MODULE B ANSWER: Yes, the violation of a constraint must be diagnosed when the criteria for the constraint is violated across module definitions. For example: MODULE C INTEGER :: I END MODULE C MODULE D USE C, X=>Y END MODULE D In section 11.3.2, "Use Association", the second constraint requires that the Y in module D be a public entity of module C. This example violates this constraint and diagnosis is required. However, the sample code in the question is standard conforming; thus no diagnostic is required. The constraints cited in the question do not apply because the type X is not declared to be private in the module A, where X is defined. The type X is public. The "PRIVATE :: X" statement in module B does not change the public nature of the type X as defined in module A. The type X is not a public entity of module B, but it is still a public entity of module A. Therefore, the type Y does not have a private component and the function F does not have a private type. Interpretation 161 discusses this issue in more detail and provides relevant citations. REFERENCES: Defect item 161 EDITS: None. SUBMITTED BY: Maureen Hoffert HISTORY: 92-225 m123 Submitted 93-024 m124 Response adopted (14-3). 93-111 m125 ballot, return to subgroup based on Hirchert comment Consider restricting constraints to "within a scoping unit" 93-137r m125 Based on comments returned with the X3J3 letter ballot following m124, the revised response, containing the opposite answer, was prepared, passed, and then withdrawn (see 93-177) 93-177 an alternate response (see 93-137) 93-220 m126 withdrawn 95-015r1 m132 revised response references interp 161. Note that this should not proceed to the next STATUS level, unless 161 is also at that level. -------------------------------------------------------------------------------- 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 draft response 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 cancelled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 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. -------------------------------------------------------------------------------- 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 paragraph after the first paragraph in section 13.2.2: "In a reference to an intrinsic subroutine, the actual arguments associated with INTENT (OUT) and INTENT (INOUT) dummy arguments must not be storage associated with any other actual argument, except that the FROM and TO arguments for the MVBITS subroutine may be the same variable." SUBMITTED BY: Dick Weaver HISTORY: 94-121 m129 submitted 95-023r1 m132 draft response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000185 TITLE: What is the allocation status of an array after an allocation failure? KEYWORDS: ALLOCATE, POINTER, DEALLOCATE, status DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION:It does not appear that the standard defines the allocation status of an array if an ALLOCATE statement fails and returns a nonzero STAT= value? Given a program segment like: REAL, ALLOCATABLE, DIMENSION(:) :: A,B,C ALLOCATE(A(10), B(10), C(10), STAT = ISTAT) Question 1: If "ISTAT" comes back non-zero, is it legal to deallocate the arrays and try to reallocate them with smaller sizes? Question 2: If instead of allocatable arrays, the variables had been pointers, is it legal to NULLIFY them? Question 3: Are the answers to questions 1 and 2 different if a single array is allocated rather than a list? Question 4: If a DEALLOCATE fails for a list, what is the allocation status of the arrays? Question 5: Is it acceptable to use the ALLOCATED and/or ASSOCIATED functions to attempt to recover from a failure? Question 6: 6.3.1.1 might be read to mean that successful allocation makes the arrays "currently allocated" and otherwise leaves them "not currently allocated". But that's not an obvious reading of the text. In some ways I/O is similar to allocate (they both process a list of things and have a STAT= clause). If an input statement fails then everything in the list becomes undefined. Does that apply by analogy to ALLOCATE? ANSWER 1: Yes. Note that one or more of the arrays is expected to have an allocation status of "currently not allocated", due to the error which occurred. See the Discussion below. Note that this example only used allocatable arrays. If a pointer appears in a DEALLOCATE statement, its pointer association status must be defined (section 6.3.3.2). See the Discussion below. ANSWER 2: Yes. See section 14.6.2.3. ANSWER 3: No, the answers are the same. See Answer 6 below. ANSWER 4: Whether the allocation status of the array is currently allocated or not currently allocated is processor dependent. The standard does not specify what the allocation status (or pointer association status) of arrays (or pointers) specified in a DEALLOCATE statement will be when an error condition occurs during execution of a DEALLOCATE statement. ANSWER 5: For ALLOCATED, yes. For ASSOCIATED, it depends on the pointer association status of the pointer at the time the ASSOCIATED intrinsic is called. The ALLOCATED intrinsic may be called with any allocatable array whose allocation status is either currently allocated or currently not allocated. The ASSOCIATED intrinsic must not be called with a pointer whose pointer association status is undefined (section 6.3.3.2). See the Discussion below. ANSWER 6: No. The standard does not require a processor to allocate the variables specified in an ALLOCATE statement as a group; therefore, a processor may successfully allocate some of the arrays specified in an ALLOCATE statement even when that ALLOCATE statement assigned a positive value to the variable specified in the STAT= specifier. Discussion: Only when the allocation status of an array is undefined is it illegal to specifiy the array in an DEALLOCATE statement. The only way for an allocatable array to have a status of undefined is described in section 14.8, item (3). If an array specified in a DEALLOCATE statement has an allocation status of not currently allocated when the DEALLOCATE statement is executed, an error condition occurs as described in section 6.3.3.1. The behavior of the DEALLOCATE statement in the presence of an error condition is described in section 6.3.3. Immediately after the execution of an ALLOCATE statement, all allocatable arrays specified in that ALLOCATE statement will have a defined allocation status (either currently allocated or currently not allocated). When a pointer is specified in an ALLOCATE statement which fails (assigns a positive value to ISTAT in this example), then the pointer association status of that pointer will not be changed if the allocation failed for that particular pointer. If that pointer previously had a pointer association status of undefined, it will still have a pointer association status of undefined immediately after the ALLOCATE statement is executed; therefore, it would be illegal to specify that pointer in a DEALLOCATE statement (section 6.3.3.2) or in a call to the ASSOCIATED intrinsic (section 13.13.13), unless the allocation status of the pointer was first changed to be defined (either associated or disassociated). EDITS: None. SUBMITTED BY: Dick Hendrickson HISTORY: 94-296 m131 submitted 95-039 m132 draft response, approved u.c. -------------------------------------------------------------------------------- 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 non-standard. 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 specifiy 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 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". 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. -------------------------------------------------------------------------------- NUMBER: 000192 TITLE: Ambiguity of dummy procedures in interface bodies KEYWORDS: dummy procedures, interface bodies DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: It appears that it may not be possible to identify from a procedure interface body which, if any, of its dummy arguments are dummy procedures. This arises from the fact that it is not necessary to give an explicit interface for dummy procedures, or even to specify the EXTERNAL attribute for them (the latter only being necessary for procedures that are used as actual arguments). Even if it were mandatory to (at least) specify EXTERNAL for dummy procedures, this would still not resolve them into subroutines and functions, given that typing may be implicit. For example, in: INTERFACE FUNCTION F (A,B,C) END FUNCTION F END INTERFACE each of the arguments could be a dummy scalar variable, a dummy function or a dummy subroutine. It appears that an explicit interface should identify dummy procedures and their nature (function or subroutine, and result type in the former case). Section 12.2 of the F90 standard ("Characteristics of Procedures") does not seem to give much guidance: section 12.2.1.2 states that a dummy procedure's characteristics only include its characteristics *as* a procedure if its interface is explicit, which is not very illuminating. Question 1: Should a procedure interface body unambiguously identify dummy procedures and their nature (i.e. function or subroutine)? Question 2: If so, is the EXTERNAL attribute mandatory for dummy procedures in an interface body, if they do not themselves have explicit interfaces? Question 3: If so, how are dummy functions and subroutines distinguished given that typing may be implicit? ANSWER: Answer 1: No. The interface body must identify each dummy argument that is a procedure by means of one of the following : -- an EXTERNAL statement for the argument -- a type declaration statement for the argument and the argument also has the EXTERNAL attribute -- an interface block for the argument. Where an interface block is present the interface body will allow the disambiguation of the dummy procedure as a subroutine or function. Where a type declaration statement is present the dummy procedure is identified as a function. Where only an EXTERNAL statement is present it is not possible to disambiguate the procedure as a subroutine or function. Answer 2: Yes Answer 3: A dummy argument that is a procedure may be identified as a function by its appearance in a type declaration statement or in a function statement within an interface body for the argument. A dummy argument that is a procedure may be identified as a subroutine by its appearance in a subroutine statement within an interface body for the argument. Discussion: The necessity to disambiguate dummy arguments that are procedures from dummy arguments that are not procedures is described in the response to defect item 000063. Section 12.3.2.1 (page 168) states that an interface body specifies all of a procedure's characteristics. Section 12.2.1.2 indicates that the characteristics of a dummy procedure are the explicitness of its interface, its characteristics as a procedure if the interface is explicit and whether it is optional. So, if a procedure P has a dummy procedure with an implicit interface the characteristics of the dummy procedure do not include whether it is a function or subroutine. Therefore it is not necessary that an interface block for P disambiguate the dummy procedure as a function or subroutine. If by contrast the interface for the dummy procedure is explicit in the scope of P, any interface body for P must include a nested interface body for the dummy procedure. This is indicated in the standard from the texts of sections 12.2, 12.2.1.2 and 12.3. Section 12.3 specifies that the characteristics of a procedure are fixed. Section 12.2 indicates that the characteristics of a procedure includes the characteristics of its dummy arguments. Finally, section 12.2.1.2 states that the characteristics of a dummy procedure include the explicitness of its interface. So any interface block for P must incorporate a nested interface block for the dummy procedure that specifies all these characteristics. EDITS: None SUBMITTED BY: John Merlin HISTORY: 94-307 m131 submitted 95-054r1 m132 draft response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000195 TITLE: INQUIRE with preconnected files KEYWORDS: INQUIRE statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: If unit 3 is preconnected to file PDG, which does not exist, then consider the following fortran-90 source: PROGRAM PETE CHARACTER*50 FM INQUIRE(UNIT=3, FORM=FM) END The notes (section C.9.4, page 278, lines 11-17) state that 'For a preconnected file that does not exist, a form may be established or the establishment of a form may be delayed until the file is created'. QUESTION 1: Where in the actual standard is there anything that substantiates the notes that the form may be established as a preconnection property or that it may be delayed. QUESTION 2: If a processor delays the establishment of a form until the file is created, then what is returned in variable FM in the program above? The standard does not seem to cover this case, all it covers is a) if the connection is for formatted b) if the connection is for unformatted c) if there is no connection There seem to be similar problems with INQUIRE with RECL, BLANK and DELIM specifiers on a similar file. ANSWER 1: The standard does not clearly say that the establishment of a form may be delayed. It is inferable from other text and the lack of an explicit prohibition. ANSWER 2: The standard does not specify what is returned in the variable FM in this case. Therefore, the processor is free to choose any value. Some of the other specifiers may also return processor dependent values for this example. Any property of the connection or file that depends on: 1) the "form" or "access" of the file connection, or 2) is only allowed for a file with a particular "form" or "access", may have a processor dependent value returned by the INQUIRE statement for that property, for this particular example. Discussion: In several places the standard talks about a form being in the allowed set of forms. A processor may allow (but is not required to allow) some files to be OPENed with either a FORM value of FORMATTED or UNFORMATTED. In section 9.3.4.4 (OPEN statement, FORM= specifier), the standard states: "For a new file, the processor creates the file with a set of allowed forms that includes the specified form". This implies that a processor may delay establishing a form for a file until the file is created. And in section 9.3.2, 3rd paragraph, the standard states: "A file may be connected and not exist. An example is a preconnected external file that has not yet been written (9.2.1.1)." So, a preconnected file need not exist until the file is referenced in a data transfer statement, and the establishment of the form may be delayed until the the file is created. If the processor delays establishing a form until the file is created, the first data transfer statement to reference a non-existent preconnected file will establish the form, and it is incumbent upon the user to only use that form. EDITS: None. SUBMITTED BY: Peter Griffiths HISTORY: 95-014 m132 submitted 95-018 m132 draft response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000196 TITLE: TARGET dummy arguments and element sequence calls KEYWORDS: argument - dummy, argument - actual, TARGET attribute, element sequence DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: In a call, if an actual argument is an array element of a dummy argument that is not assumed-shape but has the TARGET attribute, does the corresponding dummy argument have to be scalar? Section 12.4.1.1, "Arguments associated with dummy data objects", states: "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element." Thus examples such as the following are standard conforming: INTEGER :: A(10) CALL SUB(A(4)) END SUBROUTINE SUB(ARRAY) INTEGER :: ARRAY(4) ... This question is asking whether examples such as the following are standard conforming. PROGRAM P INTEGER, TARGET :: ACTUAL(100) CALL SUB(ACTUAL(1:20:2)) CONTAINS SUBROUTINE SUB(DUMMYTARGET) INTEGER, TARGET :: DUMMYTARGET(10) CALL SUBARRAY(DUMMYTARGET(5)) ! DUMMYTARGET(5) and DUMMYTARGET(6) ! do NOT represent contiguous pieces of ! storage. END SUBROUTINE END PROGRAM SUBROUTINE SUBARRAY(DUMMYARRAY) INTEGER :: DUMMYARRAY(2) DUMMYARRAY = 5 END SUBROUTINE ANSWER: Yes, the corresponding dummy argument must be scalar. Discussion: Array elements of an array that is assumed-shape or a pointer array are not allowed to appear as the actual argument when the corresponding dummy argument is not scalar. The text quoted from the standard that makes this restriction should have also made a similar restriction if the actual argument is an array element of a dummy argument with the TARGET attribute. An edit is provided to extend the restriction. Assumed-shape arrays, pointer arrays and dummy argument arrays with the TARGET attribute may represent non-contiguous storage. To allow array elements of such arrays to be passed to routines expecting a contiguous array would mean that most implementations would make a copy of the array prior to the call. If no explicit interface is available an implementation may not know if the routine being called with an array element actual argument, is expecting a scalar or an array. The implementation would not know if the copy was necessary or not; it would make the copy anyway. To avoid such unnecessary copying, it is better to restrict calls such that if the actual argument is an array element of an assumed-shape array, a pointer or a dummy argument array with the TARGET attribute, that the corresponding dummy argument must be a scalar. EDIT: 1. In Section 12.4.1.1, replace the sentence [173:18-20] "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element." with "If the actual argument is scalar, the corresponding dummy argument must be scalar unless the actual argument is an element of an array that is not (1) an assumed-shape array, (2) a pointer array, or (3) a dummy argument array with the TARGET attribute, or a substring of such an element." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-031r1 m132 submitted with proposed response, approved u.c. -------------------------------------------------------------------------------- NUMBER: 000198 TITLE: Characteristics of dummy procedures KEYWORDS: argument - optional, characteristics, dummy procedures, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.4.1.2 "Argument associated with dummy procedures" states: "If the interface of the dummy procedure is explicit, the characteristics of the associated actual procedure must be the same as the characteristics of the dummy procedure (12.2)." Section 12.2.1.2 "Characteristics of dummy procedures" states: "The characteristics of a dummy procedure are the explicitness of its interface (12.3.1), its characteristics as a procedure if the interface is explicit, and whether it is optional (5.1.2.6, 5.2.2)." This would imply that the following two examples are not standard conforming, as the characteristics of ARG1 are not the same as the characteristics of ARG2, and ARG2 has an explicit interface. Example 1: SUBROUTINE S(ARG1) EXTERNAL ARG1 INTERFACE SUBROUTINE SS(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE SS END INTERFACE CALL SS(ARG1) ! ARG2 has an explicit interface and that is ! one of its characteristics but ARG1 has an ! implicit interface as one of its characteristics END SUBROUTINE S Example 2: SUBROUTINE T(ARG1) OPTIONAL ARG1 INTERFACE FUNCTION ARG1(I) END FUNCTION END INTERFACE INTERFACE SUBROUTINE TT(ARG2) INTERFACE FUNCTION ARG2(I) END FUNCTION END INTERFACE END SUBROUTINE TT END INTERFACE IF (PRESENT(ARG1)) CALL TT(ARG1) ! ARG1 is optional and that ! is one of its characteristics. ARG2 is not ! optional and that is one of its characteristics. END SUBROUTINE T Are the code fragments standard conforming? ANSWER: Yes, both the code fragments are standard conforming. Discussion: In the text cited from 12.4.1.2, the reference to 12.2 was there to indicate that the requirement is that the characteristics of the dummy procedure as a procedure match those of the characteristics of the actual procedure as a procedure. The other characteristics of a dummy procedure (the explicitness of its interface and whether it is optional) were not meant to be included in the reference. An edit is included to clarify this intent. EDIT: Section 12.4.1.2, [173:36] change "dummy procedure (12.2)." to "dummy procedure, with respect to the characteristics of a procedure as listed in 12.2." SUBMITTED BY: Janice C. Shepherd HISTORY: 95-042 m132 submitted, with proposed response, approved 9-4, 95-067 m132 alternate edit proposed, approved u.c.