From owner-sc22wg5 Tue Jul 24 10:46:25 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 KAA01513 for ; Tue, 24 Jul 2001 10:46:25 +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 JAA05833; Tue, 24 Jul 2001 09:46:23 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id JAA14088; Tue, 24 Jul 2001 09:48:34 +0100 (BST) Date: Tue, 24 Jul 2001 09:48:34 +0100 (BST) From: John Reid Message-Id: <200107240848.JAA14088@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: (SC22WG5.2152) Dynamic arrays and interfacing with C Cc: donev@pa.msu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: Richard Maine X-Sequence: SC22WG5@dkuug.dk 2152 Errors-To: SC22WG5-request@dkuug.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 23 Jul 2001 13:03:14 -0700 (PDT) To: SC22WG5@dkuug.dk cc: donev@pa.msu.edu Subject: (SC22WG5.2152) Dynamic arrays and interfacing with C In-Reply-To: <200107231745.TAA98794@dkuug.dk> References: <200107231745.TAA98794@dkuug.dk> X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid John Reid writes: > Here is a draft of a paper that I have prepared with the help of > Aleksandar Donev for the London meeting in the context of review the > current draft F2000 standard. > > Comments, please. I won't be at the London meeting, and the J3 meeting before it has already happened, so email is my only avenue for commenting on this. (That in itself concerns me - to have what looks like a major new proposal with this little chance for review before it possibly becomes a new requirement.) This seems like an awfully large new requirement/proposal for this late in the process. We are now supposed to be in the integration phase, which is all to short for a good job as is. I would expect this to substantially impact integration. > It is impossible for a Fortran procedure, while > being called from C, to allocate an array and make that array available > to the C code. I do not believe that to be the case. It appears to me that the Fortran subroutine could use a saved, target, allocatable array, in conjunction with the C_LOC intrinsic to do such a thing. I agree the use of allocatable would place some pretty significant restrictions on the usability of this. I would think that allowing C_LOC to take pointer arguments would be a far simpler way of extending this. Even if we add some new definitions to restrict the class of pointers it could reference to those that were "contiguous", I'd think it a lot less complication to define that than to introduce a whole new class of pointer, with a new syntax and lots of new interactions to worry about. > Conversely, it is impossible for a C function, while > being called from Fortran, to allocate an array and make that array > available to the Fortran code. Agree. And a hugely simpler solution to that was proposed and rejected. To my knowledge, the only reason for the rejection was that it did allow Fortran pointers to point to C allocated things. I don't think the rejection was based on the specific mechanism so much as the end result. If we want to allow this, I propose that we resurrect that idea, which was very simple and really had no other complications that I can think of. (Ok, I'm biased; I liked the idea before, and I still do.) That idea was basically to have an intrinsic that generated a Fortran pointer from an address and a mold. See paper J3/00-168. One could argue spelling trivia, but the idea seems pretty simple and workable to me. > It also has the side benefit of providing a dynamic array within > Fortran that has far less storage overheads than allocatable or > pointer arrays. I don't believe that side effect is, in itself, of major enough impact to justify such a late proposal. The C/Fortran interop aspects, which I do agree are important, have, in my opinion, simpler solutions, as described above. I would think it more appropriate to pursue those solutions than this new syntax. In particular, as long as we allow some way to dereference C pointers, it is going to be hard (in my opinion) to explain why we don't have something like the proposal of paper j3/00-168. So let's see how much of the problem that solves by itself. -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain