From owner-sc22wg5@open-std.org Mon Dec 6 19:32:38 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id C27E3C3BA1C; Mon, 6 Dec 2010 19:32:38 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by www2.open-std.org (Postfix) with ESMTP id E378EC178E3 for ; Mon, 6 Dec 2010 19:32:35 +0100 (CET) Received: from source ([136.162.34.13]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKTP0sQtLoh/zvX9r2qL+dDNs325cdo/zj@postini.com; Mon, 06 Dec 2010 10:32:37 PST Received: from fortran.us.cray.com (fortran.us.cray.com [172.31.19.200]) by stplmr01.us.cray.com (8.14.3/8.13.8/hubv2-LastChangedRevision: 12441) with ESMTP id oB6IWXJv023722; Mon, 6 Dec 2010 12:32:33 -0600 Message-ID: <4CFD2C74.3020002@cray.com> Date: Mon, 06 Dec 2010 12:33:24 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4375) [ukfortran] WG5 informal ballot re Interop. TR References: <20101108175805.5B97EC178E5@www2.open-std.org> <20101206103130.1AE8AC178E3@www2.open-std.org> <20101206134148.834A7C178E4@www2.open-std.org> <4CFD0D53.8030501@cray.com> <20101206172004.67170C178DA@www2.open-std.org> In-Reply-To: <20101206172004.67170C178DA@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Ah, OK. You are proposing added restrictions on how TYPE(*) could be used in a Fortran-Fortran call. I have fewer problems with that idea, but would still want the MPI folks to agree that this restriction is not a problem for them. Cheers, Bill On 12/6/10 11:19 AM, Aleksandar Donev wrote: > On 12/06/10 11:20, Bill Long wrote: >> However, one of the original desires of the MPI users was to have >> >> type(*),dimension(*) >> >> map to a void * dummy parameter and have only the address passed. I >> think this would be an often used form. > And I did not propose changing that. On the C side it is still void*. > The issue is what happens when a Fortran routine has such a dummy. > > Let me write my proposed solution, this time without typos (I hope) but > I won't try to get the language perfect: > > An assumed-type dummy argument that is of assumed-shape or assumed-rank > shall not correspond to an explicit-shape or assumed-size actual > argument that is itself an assumed-type dummy argument. > [I think allocatables and pointers are OK. Also note that a CLASS(*) > actual is allowed.] > > Note for Rationale: This ensures that a caller can always pass type > information for an assumed-shape or assumed-rank to the callee, even > though there is no means to inquire it within Fortran. > > Thanks, > Aleks > -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101