From jkr@jkr.cc.rl.ac.uk Mon Apr 30 11:43:54 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id LAA45736 for ; Mon, 30 Apr 2001 11:43:53 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id KAA17724 for ; Mon, 30 Apr 2001 10:44:06 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id KAA29122 for SC22WG5@dkuug.dk; Mon, 30 Apr 2001 10:46:12 +0100 (BST) Date: Mon, 30 Apr 2001 10:46:12 +0100 (BST) From: John Reid Message-Id: <200104300946.KAA29122@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Revised draft response for interp. 31 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5, Here is a revised draft response for interp. 31. Comments, please, before I send this to J3. John Reid. J3/01-xxx Date: 30 April 2001 To: J3 From: John Reid Subject: Interpretation 31 (Association of pointer function result with INTENT(OUT) dummy argument) Interpretation 31 is not a new interpretation. It failed its J3 ballot, with 5 NO votes against 10 YES votes and one YES with comments. The present response and the ballot comments (00-329) and are appended for your convenience. I sent earlier drafts of this paper to the WG5 list for comments and would like thank those that helped me get to this version, specially Kurt, Van, Henry, and Malcolm. The basic problem is to decide whether a pointer function reference with a valid target can be associated with a nonpointer dummy argument that has intent(out) or a nonpointer dummy argument that is redefined. That is, whether a pointer function reference is treated as an expression in this context. The standard is ambiguous, as the question makes clear. It is my view now that an edit to the standard is needed. The old draft said: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. I have tried the example code on the following compilers: Nag, SUN, Epc, IBM, Compaq, Fujitsu, Salford, NASoftware. All but NASoftware reject it with a clear message. This is consistent with the old draft reply. Note that a majority voted YES on this. An alternative view is that the program conforms to the Standard because the dummy argument is associated with the target of the actual argument (see [200:30-32], quoted below). This paper provides drafts for both views, each with edits. .................................................. NUMBER: 000031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. The edits add additional text to make this clear. EDITS: In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(OUT)' [53:31], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(INOUT)' [53:36], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, add at the end of the last paragraph [53:38] 'The dummy argument is not definable unless the actual argument is a variable that is definable.'. In subclause 12.4.1.1, on line 20 of page 201 [201:20], add 'a variable that is' before 'definable'. ....................................................................... Alternative response ANSWER: It was intended that this program be standard conforming. The dummy argument is associated with the target of the actual argument, as the text from [200:30-32] quoted above states. In this case, the actual argument has a valid target and the target is definable. The edit adds additional text to make this clear. EDIT: On page 200, subclause 12.4.1.1, at the end of the paragraph that starts 'If the dummy argument is not a pointer' [200:32], change 'target.' to 'target; references elsewhere in this standard to "the actual argument associated with the dummy argument" are references to the target'. ....................................................................... SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot .................................................... Old draft response ANSWER: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. EDIT: None. .................................................... Ballot comments RichB's NO vote on 000031 See IBM's comments. Malcolm's YES comment on 000031 I disagree with the other comments that the dummy argument is argument-associated with something that is not an actual argument. The dummy argument is associated with the (value of) the actual argument expression. Craig's NO vote on 000031 I agree with Van's comments. Kurt's NO vote on 000031 I agree with Van. The pointer that is the function result is not definable, but the target identified by that pointer (in this case, T) _is_ definable. In the example given, the dummy argument is associated with the target, not the pointer. [The prohibition against a function reference appearing on the left hand side of an assignment statement is syntactic in nature and has no bearing on this semantic question.] Van's NO vote on 000031 I don't know the intent of the committee, but my experience in reading the standard is that the area of argument association of pointers is murky. It is my preference that a non-pointer dummy argument is considered to be associated with a definable actual argument if the actual argument is a pointer that is associated with a definable target. The glossary entry for "definable" is not normative, and, like Henry, I could not find a normative definition for it. I prefer not to depend on non-normative text to resolve an interpretation. Henry's arguments concerning the relation between the passages he cites from 5.1.2.3 and 12.4.1 convince me that the example he provides should be standard-conforming. If the dummy argument had the pointer attribute, I would accept a conclusion that its pointer association status could not be changed, because in that case, the actual argument would be a function result. Henry's NO vote on 000031 We are inclined to agree with Van Snyder on this question. It is clear that the standard treats specially pointers that appear as actual arguments when the associated dummy is not a pointer: the dummy becomes argument associated with the target of the pointer, not with the actual argument itself. We agree the actual argument is not definable, but that seems irrelevant because the entity that is argument associated with the target is not the actual argument in this case. It seems far more likely that the drafters of the standard failed to take into account the case of a pointer actual argument that corresponds to a nonpointer dummy argument when they required that the "actual argument shall be definable" in [201:19-21] and [53:29-31]. In fact, the text cited at 5.1.2.3 [53:29-31] is particularly troublesome. To repeat, it states that: The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable. But in the case of a pointer actual argument that corresponds to a nonpointer dummy, there is no actual argument associated with the dummy. The target of the pointer is associated with the dummy, but the target is not the actual argument. We also feel that a normative definition of the term "definable" is required.