From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Aug 27 07:48:30 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 121AE3568FC; Mon, 27 Aug 2012 07:48:30 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id E4BF63568AB for ; Mon, 27 Aug 2012 07:48:27 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id q7R5mMrR072601 for ; Mon, 27 Aug 2012 05:48:25 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <5948A65E128042D8A349DCB6D1C18B06@Maru6> From: "Malcolm Cohen" To: "WG5" References: <20120817095648.607253568FA@www.open-std.org><20120824011610.86A663568D6@www.open-std.org> <20120826132105.D1E263568AB@www.open-std.org> In-Reply-To: <20120826132105.D1E263568AB@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4732) Fortran 2003 Interoperability Rationale Date: Mon, 27 Aug 2012 14:48:22 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk >The main one is procedure arguments. I can't see why they weren't allowed >(for interoperable procedures only, natch), and am concerned that I may >have missed something. One might reasonably suppose that since TYPE(C_FUNPTR) provides the necessary functionality, not just for procedure pointers as arguments but also for components, there was no pressing need for anything further. >The most likely explanation was that the wordsmithing was simpler if they >were not allowed, but was there anything else? I don't recall anything being mentioned in plenary. Keith Bierman might remember any subgroup discussion of this. Bill Long suggested: >I think we did not want to make the assumption that the internal representation >for a function pointer was the same for native Fortran and native C. Similar >to why we invented C_PTR and C_LOC. Right, we needed C_FUNPTR for procedure pointer components in interoperable structures anyway - there was a principle against misusing the POINTER attribute to confuse C pointers and Fortran pointers - but I think we could have allowed procedure dummy arguments similarly to how we allowed dummy data objects without VALUE to interoperate with C data pointers. My guess would be that this was seen as unnecessary except on the syntactic sugar level (and I would agree with that), and that there was insufficient demand for the sugar. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.