From rz48@rz.uni-karlsruhe.de Sat Feb 1 14:02:48 1997 Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id OAA28519 for ; Sat, 1 Feb 1997 14:02:44 +0100 Message-Id: <199702011302.OAA28519@dkuug.dk> Received: from ry71.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Sat, 1 Feb 1997 14:02:38 +0100 Received: by ry71.rz.uni-karlsruhe.de (1.38.193.4/16.2) id AA23952; Sat, 1 Feb 1997 14:02:37 +0100 Subject: Simple Interop examples... To: jwagener@ionet.net (Jerrold L. Wagener) Date: Sat, 1 Feb 1997 14:02:36 +0100 (CET) Cc: sc22wg5@dkuug.dk In-Reply-To: <9701311041.AA17246@Zvyvogs> from "Jerrold L. Wagener" at Jan 31, 97 10:41:17 am From: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) Reply-To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 4133 Dear Jerry, here is my response to some of your questions. Since it might be that other people have similar questions, I copy them to the full list: > I perhaps read the draft too quickly and missed the point, but it still > seems like any Fortran program that is going to call a C function must > use the c_type kinds outside of the interface. Perhaps you can point me > to that part of the draft which allows, for example, the Fortran > expression j+c_func(k), where j and k are Fortran default integers and > the function call should return a default integer, where the c function > prototype is int c_func(int), and where the interface specifies the > necessary transformations in the event that kind c_int is not the same > as default kind integers. This is the sort of simple case I am talking > about, and I missed seeing that capability in a quick reading of the draft. The interface to the above C function would be BIND(C, "c_func") FUNCTION c_func( i ) USE ISO_C, ONLY: c_int INTEGER(c_int) [ , INTENT(IN) ] :: i INTEGER(c_int) :: c_func END FUNCTION c_func Using the RESULT VALUE of type INTEGER(c_int) is governed by normal Fortran rules for conversions in expressions, so J+C_FUNC(something-legal) will suffer conversion according to the normal rules for the addition of a type-of-J object and an INTEGER(c_int) object. This has NEVER been the issue. Associating an actual ARG with dummy I is governed by 3.4.2.1, which is new and as I wrote in my email announcing N1237 (97-108) is also VERY important. It states (p.31, in the par. before Note 3.40) that "... the actual argument ... shall have a type and type parameters for which assignment to a variable of the type and type parameters of the dummy argument is defined by IS~1539-1 or this Technical Report. % The C function parameter is assigned the value of the actual argument, converted as if by such assignment to the type and type parameters of the dummy argument." So you may write J=C_FUNC(123_Int8) or J=C_FUNC(123_Int64) or even J=C_FUNC(12.3D0), because assignment from 8-bit INTEGERs, 64-bit INTEGERs, and even from DOUBLE PRECISION to INTEGER(C_INT) is defined in IS~1539-1 (assuming the existence and obvious meanings for kinds Int8 and Int64). Note that there is NO CONVERSION back to the actual's type after the call. This is an obvious implication of call-by-value (the actual argument SHALL NOT be modified by the call, so why convert back???), which everybody seems to have overlooked for more than a year... This is also the reason that this form of argument association is only allowed if the dummy arg. is not a pointer (or an array, which IS a pointer in C): the pointer's TARGET may be modified, so the type must match and you need to use the C type kind parameters on the Fortran side. > Incidentally, I like your shorter names for the C kinds (e.g., c_int), > but I'm puzzled why you chose things like c_flt instead of c_float > or c_real. Introducing a third spelling seems like bad design; > seems like the paradigm ought to be c_ or > c_ consistently. These ancronyms are already in use, see Note 3.9. I chose them because they are SHORT. If you used full type specifiers, you'd end up with C_LONG_DOUBLE instead of C_LDBL which is more than a factor of two. If you start typing lots of BIND(C) interface specifications, you'll probably likt to have short kind names. If not, you are free to just "USE ISO_C, c_float => c_flt" ... Thanks, Michael ====================================================================== Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ---------------------------------------------------------------------- University of Karlsruhe RFC822: hennecke@rz.uni-karlsruhe.de Computing Center (G20.21 R210) No longer on BITNET :-( Zirkel 2 * P.O. Box 69 80 Phone: +49 721 608-4862 D-76128 Karlsruhe Fax: +49 721 32550 ======================================================================