From zongaro@VNET.IBM.COM Wed May 22 15:27:02 1996 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id PAA18419 for ; Wed, 22 May 1996 15:26:53 +0200 Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0576; Wed, 22 May 96 09:26:23 EDT Received: by TOROLAB (XAGENTA 4.0) id 1550; Wed, 22 May 1996 09:29:02 -0400 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA26921; Wed, 22 May 1996 09:26:24 -0400 From: (Henry Zongaro) Message-Id: <9605221326.AA26921@twinpeaks.torolab.ibm.com> Subject: Liaison Report on Interoperability with C To: sc22wg5@dkuug.dk Date: Wed, 22 May 1996 09:26:22 -0400 (EDT) Cc: sc22wg5-interop@ncsa.uiuc.edu, hennecke@rz.uni-karlsruhe.de X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 6094 Hello, Attached is the latest liaison report on Interoperability, produced at last week's X3J3 meeting. Thanks, Henry X3J3/96-106R1 (Page 1 of 3) To: X3J3, WG5, Michael Hennecke From: /Interop Subject: Liaison Report: Interoperability of Fortran and C References: ISO/IEC JTC1/SC22/WG5 N1178 (X3J3/96-069), X3J3/95-295, X3J3/95-293R1, X3J3/96-039R1 N1178 proposes mechanisms through which Fortran programs can reference procedures defined in C in a portable fashion. X3J3 concurs with the need for such a facility, but has some points of concern about the current draft report. 1) After careful consideration, X3J3 has decided that it prefers the concept of placing more of the responsibility for interoperability on the processor. For that reason, X3J3 would prefer to see a MAP_TO attribute as sketched out in X3J3/95-295 ("HPF Calling C Interoperability Proposal"). Though the precise syntax for such a MAP_TO facility was not resolved, there were some suggestions: (i) Use kind type parameters to specify the mapping, rather than C data types, or (ii) Use C data types specified in a character constant. Some sort of "recursive" MAP_TO was recommended to handle the problem of mapping to C structures, rather than associating BIND with derived type definitions. There was also some feeling that a merger of the two proposals might be fruitful - giving a user explicit control when desired, leaving things up to the processor when desired. 2) X3J3 would prefer to see the BIND attribute be renamed as EXTRINSIC, simply because there exist a number of Fortran implementations which use the EXTRINSIC keyword for inter-language calling issues, as specified by HPF. 3) It is not clear from section 3.1 of the draft TR, whether an external procedure with an implicit interface may be specified in the BIND statement. X3J3 would prefer that BIND be permitted only for procedures with explicit interfaces. In addition, it is not clear whether the BIND statement can be specified for the result variable of a procedure whose interface is defined by an interface body. X3J3 would prefer that this not be allowed, and that, for procedures, the BIND attribute be specified only on the or the . X3J3 considers BIND in this situation to be a property of the procedure as whole, analogous to PURE and RECURSIVE, rather than a property of the result variable. X3J3/96-106R1 (Page 2 of 3) 4) X3J3 believes that rather than pursuing a solution for C character strings involving a new derived type definition, the TR should specify a module which provides a set of procedures for conversion between Fortran character strings and character arrays with a character length parameter of one and a kind parameter of C_CHAR_KC. These character arrays would correspond to C character strings. For example, a generic procedure named CSTRING might handle the conversion from a Fortran character value to a C null-terminated string. PROGRAM P USE ISO_C_STRINGS INTERFACE BIND(C, 'THING') SUBROUTINE SUB(STR) USE ISO_C_KINDS CHARACTER(LEN=1, KIND=C_CHAR_KC) :: STR(*) END SUBROUTINE SUB END INTERFACE CALL SUB(CSTRING('HELLO, FORTRAN!')) END PROGRAM P 5) X3J3 concurs with the need for a type alias statement to handle C typedefs. However, it has some reservations about the possibility for interaction between the proposed type alias statement and the Parameterised Derived Types proposal, and possibly with any Object Oriented Fortran features which might be a part of Fortran 2000. 6) Rather than creating a new to handle stdargs, X3J3 would prefer that additional optional "linkage" specifiers be permitted on the BIND specifier, for example, BIND(C, 'FOO', STDARG). If, at some point in time, it is decided that it is desirable to support interoperability between Fortran and some other language which supports several combinations of linkage, it is easier to permit the various combinations to be individually specified, than it is to create distinct keywords for each combination. 7) X3J3 feels that there must be some specification of the fact that the dummy arguments specified in the interface body for a procedure with the BIND specifier must match the arguments of the associated C function. That is, that the order of the arguments is the same in the two. In some common existing implementations of interoperability, the orders of the two are reversed. X3J3/96-106R1 (Page 3 of 3) 8) X3J3 concurs with the need to specify whether the arguments of a procedure defined by C are to be passed "by value" or "by reference". X3J3 would prefer some sort of "BYREFERENCE" approach versus the "INTENT" approach, though all of the rules of the selected method must be specified. 9) X3J3 feels that, in Section 3.3.1 of the draft TR, function results of C procedures must be prohibited from being: (i) of type COMPLEX or LOGICAL; (ii) arrays; or (iii) characters of length other than one.