From J.L.Schonfelder@liverpool.ac.uk Tue Feb 22 16:30:52 1994 Received: from ns.dknet.dk by dkuug.dk with SMTP id AA03762 (5.65c8/IDA-1.4.4j for ); Tue, 22 Feb 1994 19:08:24 +0100 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by ns.dknet.dk with SMTP id AA15724 (5.65c8/IDA-1.4.4j for ); Tue, 22 Feb 1994 18:08:21 +0100 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <01097-0@mailhub.liverpool.ac.uk>; Tue, 22 Feb 1994 17:00:15 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9402221630.AA10872@uxe.liv.ac.uk> Subject: Re: (x3j3.1994-89) 006 items To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Tue, 22 Feb 1994 16:30:52 +0000 (GMT) In-Reply-To: <9402152257.AA21462@newton.ncsa.uiuc.edu> from "Janice Shepherd" at Feb 15, 94 05:39:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4488 X-Charset: ASCII X-Char-Esc: 29 Janice Shepherd wrote stuff deleted.... > > The status of interpretation 41 will be reset to "X3J3 consideration in > progress" as it refers to edits in interpretation 125 that no longer > exist. (It should have had a HOLD on it pending the outcome of 125). > stuff deleted.... > > NUMBER: 000125 > TITLE: Copy in/copy out of target dummy arguments > KEYWORDS: argument - dummy, target, interface - explicit, 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 dummy arguments that have 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 passing arguments that have the TARGET attribute. > > 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 intent of the standard > was to allow copy in/copy out but not to require it. The edit supplied > clarifies this intent. > > Discussion: The changes apply only to target dummy arguments. > > REFERENCES: ISO/IEC 1539:1991 (E) sections 12.4.1.1, and C.12.8. > > EDITS: > > 1. In section 12.4.1.1, in the paragraph that starts "If the actual > argument has the TARGET attribute," [173:14] > change "do not become" > to "do not necessarily become" > > 2. In section 12.4.1.1, in the paragraph that starts "If the actual > argument has the TARGET attribute," add to the end of the first > sentence [173:16] > "that is, whether the pointers associated with the actual argument > become associated with the dummy argument is processor > dependent." > > SUBMITTED BY: Jon Steidel - X3J3/93-095 > LAST SIGNIFICANT CHANGE: 93-11-12 000125 ballot failed > HISTORY: X3J3/93-095 m124 submitted with draft response and adopted (15-1) > X3J3/93-111 ballot, returned to subgroup based on Leonard, Maine > comments. Problems with placement of edit 1, content of > edit 4 > X3J3/93-139r m125 revised response adopted 17-1. > X3J3/93-255r1 m127 ballot failed 13-10 > X3J3/94-092r1 m128 revised response, approved 11-5 I remain very seriously unhappy about this interpretation. I believe we have a mess in this area. A strict interpretation of one section of the book would indicate that the above is(was) the intention, but given that: a) we have a requirement that if TARGET is specified for the dummy, the actual argument must have the target attribute. b) we require intefaces to be explicit if the dummy argument is a target we clearly intended target arguments to be handled differently from normal variables. It was and is my belief that this was done to ensure that for target arguments the passing method would be by reference not by value and that the association between the targets and any pointers would in fact be preserved across the call boundary. I do not believe it was the intention to allow copy in/copy out semantics in this case. The above interpretation is guaranteed to produce maximum surprise for the user. That we have a flaw in the standard I am convinced is true, and it is a flaw that we need to fix. The above is not a fix it compounds the flaw by codifying the illdefined and unpredictable. With this interpretation I cannot make any assumptions about the state of any pointer dummy arguments to procedures with target dummy arguments and any associations that existed before or after a call to such a procedure. The association status of the pointer actual argument after a call is machine dependent. This is seriously unhelpful and not what a responsible standard should be defining. I would like to see this issue revisited and the outcome changed. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk