From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Aug 27 09:18:01 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 0B290356908; Mon, 27 Aug 2012 09:18:00 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by www.open-std.org (Postfix) with ESMTP id 194A13568FC for ; Mon, 27 Aug 2012 09:17:59 +0200 (CEST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42668) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1T5taA-00004u-R3 (Exim 4.72) (return-path ); Mon, 27 Aug 2012 08:17:58 +0100 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1T5taA-00087d-Bv (Exim 4.72) (return-path ); Mon, 27 Aug 2012 08:17:58 +0100 Received: from [31.185.169.183] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 27 Aug 2012 08:17:58 +0100 Date: 27 Aug 2012 08:17:58 +0100 From: "N.M. Maclaren" To: WG5 Subject: Re: [ukfortran] (SC22WG5.4733) Fortran 2003 Interoperability Rationale Message-ID: In-Reply-To: <20120827054830.634F03568FD@www.open-std.org> References: <20120817095648.607253568FA@www.open-std.org><20120824011610.86A663568D6@www.open-std.org> <20120826132105.D1E263568AB@www.open-std.org> <20120827054830.634F03568FD@www.open-std.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Aug 27 2012, Malcolm Cohen wrote: > >>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. > >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. Thanks very much. We all seem to be guessing along the same lines! Interestingly, the lack of sugar turns out to be a complication as far as teaching the mechanism is concerned. Instead of simply saying that BIND(C) procedure arguments are allowed in BIND(C) procedure calls just as procedure arguments are allowed in other calls, I have to explain C_FUNPTR and C_FUNLOC. Not hard, but no longer a one-liner. Regards, Nick Maclaren.