From owner-sc22wg5@open-std.org Wed Dec 10 10:43:14 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 0013FCA343D; Wed, 10 Dec 2008 10:43:13 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102]) by www2.open-std.org (Postfix) with ESMTP id 53A9BCA3439 for ; Wed, 10 Dec 2008 10:43:12 +0100 (CET) Received: from [129.187.15.179] ([129.187.15.179] [129.187.15.179]) by mailout.lrz-muenchen.de with ESMTP; Wed, 10 Dec 2008 10:43:04 +0100 Message-Id: <493F8F27.2060300@lrz.de> Date: Wed, 10 Dec 2008 10:43:03 +0100 From: Reinhold Bader User-Agent: Thunderbird 2.0.0.18 (X11/20081112) MIME-Version: 1.0 To: sc22wg5@open-std.org Subject: Re: (j3.2006) (SC22WG5.3809) Response on the TR29113 draft N1761 References: <20081209223135.06FA6C178D6@www2.open-std.org> <20081210045045.40C5DC178E6@www2.open-std.org> In-Reply-To: <20081210045045.40C5DC178E6@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Aleksandar Donev schrieb: > Hi, > > Concerning the question of whether it is intended to have only a single > Fortran descriptor (constant size) with just the fields changing for > different arrays: The intention was to not impose any particular choice. > The Fortran descriptors are opaque. Certainly it was intended that the > descriptors could be different (including byte count) for different ranks. > >> You are referring to the case I described above ('construct_foo_c'), >> suppressing which seems to make excellent sense at this point. > I guess I still don't get it. I am referring to this example: > > subroutine sub(x) bind(c) ! External procedure > real :: x(:) > end subroutine > > program test > interface > subroutine sub(x) bind(c) ! External procedure > real :: x(:) > end subroutine > end interface > > call sub(x) ! This will call two wrappers twice > end program Ah, I see. Well, since we are creating new functionality we could require all Fortran implementations with these characteristics to be CONTAINEd module procedures. I'd favor that. On the other hand (assuming one widely used name mangling scheme), we could have the processor create the symbols sub_(...) and sub(). Calls from Fortran would refer to sub_(). > > Did you intend to make this illegal? If yes, that seems contentious. If > not, how would it skip the wrappers if the compiler has no clue that the > procedure is actually written in C nor does it know the "local Fortran > name"? > >> What does the C function pass to the wrapper for arguments not >> present? >> If the C function call passes NULL > OK, that is what I wasn't sure about. How does this resolve the issue of > VALUE+OPTIONAL then? I already mentioned that some convention might be needed. This might be that the wrapper generates a local entity with default initialization. If the object does not provide default initialization, its status is undefined. I'd agree the semantics is somewhat questionable, but at least there wouldn't be any problems related to particular vendor's implementations. > >> True. But we'd then need to change the semantics of DIMENSION(*) >> in *generic interfaces*, and I don't see how this can be done while >> maintaining backward compatibility, *especially* if the scalar case >> is included. Some existing code could become invalid. > You are right. So now the question is: Is being able to use generic > interfaces enough to justify adding the new concept of > assumed-rank-and-size? Of course it would be better, but is it worth it. Wouldn't the added bonus of being able to treat character(len=*) entities in generic interface (see vararg discussion) be an incentive? > I think so, but all of WG5 ought to be convinced. > > Best, > Aleks > -- Dr. Reinhold Bader Leibniz-Rechenzentrum, Abt. Hochleistungssysteme | Tel. +49 89 35831 8825 Boltzmannstr. 1, 85748 Garching | Fax +49 89 35831 9700