From jwagener@ionet.net Thu Nov 23 20:55:11 1995 Received: from ion3.ionet.net (ion3.ionet.net [204.96.200.8]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA06259 for ; Thu, 23 Nov 1995 20:55:05 +0100 Received: from erehwon (tsip24.ionet.net [206.28.164.33]) by ion3.ionet.net (8.6.12/8.6.12) with SMTP id NAA07233 for ; Thu, 23 Nov 1995 13:54:51 -0600 X-Mailer: InterCon TCP/Connect II 2.2.1 MIME-Version: 1.0 Message-Id: <9511231400.AA25255@erehwon> Date: Thu, 23 Nov 1995 14:00:25 -0500 From: "Jerrold L. Wagener" To: sc22wg5@dkuug.dk Subject: Liaison Report on Interoperability Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline X3J3/95-293 Nov 1995 X3J3 Liaison Report on Interoperability To: X3J3, WG5, and Michael Hennecke From: X3J3/interop References: X3J3/95-294, X3J3/95-295 The draft WG5 document S6 (X3J3/95-294), entitled "Draft Interoperability TR" and the HPFF paper entitled "HPF Calling C Interoperability Proposal" (X3J3/95-295) detail the current directions being proposed for Fortran interoperability with C by WG5 and HPFF, respectively. X3J3 believes these documents are the most recent proposals for interoperability made within the two groups. The two documents differ markedly in their approaches to the problem of writing Fortran programs which use external procedures written in C. Brief outlines of the two proposals appear below, accompanied by X3J3's views on some of the technical issues. A synopsis of 95-294 -------------------- 95-294 examines some of the issues involved in having C coexist with Fortran. These include: (i) the need for a means of translating from the name of a Fortran entity to the name of a C entity, which may be complicated by the fact that C distinguishes between lower and upper case characters, whereas Fortran, outside of a character context, does not; (ii) the need for Fortran data types which are equivalent to C data types; and (iii) the need to be able to handle differences in argument calling conventions in implementations of the two languages (which is closely linked with (ii) above.) The proposal currently deals mainly with points (i) and (ii) above. Specific edits to Fortran 95 are only provided for (i). 95-294 proposes that three intrinsic modules be defined: ISO_C_KINDS, ISO_C_LIMITS_H and ISO_C_FLOAT_H. ISO_C_KINDS defines named constants whose values are Fortran kind type parameters for the character, integer and real types which correspond to the basic types of C. ISO_C_LIMITS_H and ISO_C_FLOAT_H are direct translations of the C header files, and , into Fortran. 95-294 then goes on to detail how C's derived types can be handled: (i) C's void functions be treated as subroutines by Fortran programs. (ii) void * can be handled as an integer with a special kind type parameter in Fortran. (iii) One-dimensional arrays map directly to one-dimensional arrays in C. The user needs to be aware that multidimensional arrays in C are stored row-major, while they are stored column-major in Fortran. (iv) structs can be handled by using some TRANSFER-like mechanism. (v) No specific proposal was given for unions, other than a TRANSFER-like mechanism. (vi) enums are treated as integers of default kind. (vii) typedefs are not handled. (viii) No proposal for pointers, other than item (ii), above. (ix) Function pointers were not specifically dealt with. The proposal then goes on to describe how Fortran logical and complex data could be mapped to C integers and structure, respectively. Finally, the name binding proposal for external procedures and common blocks is presented. The syntax for this is: BIND([NAME=] [, [LANG=]]) where LANG= specifies not only the language, but possibly a specific compiler. The NAME= specifier indicates the *binder* name of the procedure or common block, rather than the name by which it is known in the C code. This bind name can be used to facilitate bi-directional interoperability, not only Fortran calling C procedures. Several forms of BIND are introduced: (i) BIND(NAME='Blah') :: FUNC (ii) INTEGER, EXTERNAL, BIND(NAME='Blah') :: FUNC (iii) COMMON /BIND(NAME='Blahck') COM/ A, B, C (iv) INTEGER BIND(NAME='Blah') FUNCTION FUNC() (v) The BIND option may also be specified on the , and . Technical notes on 95-294 ------------------------- X3J3 concurs with the idea of using a module containing kind type parameters to help define the correspondence between basic types in C and intrinsic types in Fortran. This seems to provide the easiest portable method. X3J3 also concurs with the need for some method of specifying the name for the C procedure as distinct from the name by which the procedure is known in the Fortran program. X3J3 also has the following technical concerns: o There may be problems with mapping void * (or other pointers) to some kind of integer. Although pointers on most machines are of a size which corresponds to some kind of integer supported on the machine, this is not universally true. o In addition, it is not clear how the addresses of objects are to be stored in these integers with pointer kind. o Specifying the binder name of the function or extern rather than the actual name as specified in the C definition of the procedure or variable will make this proposal less portable and more confusing (unless such bind names can be placed in named constants.) In addition, such binder names could contain characters which do not correspond to characters in the Fortran character set or the processor character set. o It is not clear whether a processor can claim to conform to this TR if it does not support lower case letters. o X3J3 would like to see details of how COMMON blocks correspond to C extern variables. o It is not clear whether a processor can claim to conform to this TR if any of the kind type parameters defined by ISO_C_KINDS have a negative value. That is, is a processor required to supply integer, real and character kinds corresponding to every basic type in C? o Using TRANSFER (or some similar mechanism) to map to structs and unions in C seems very awkward. The possibility of using derived types should be explored. Possibly some new statement, such as CSTRUCT, which is analogous to the SEQUENCE statement could appear in derived type definitions. A CUNION statement would also be a possibility, although it would have a greater impact upon the standard. o The example of the ISO_C_KINDS module shows unsigned integer types having the same kind type parameters as signed types. Does C place restrictions on the ranges of values of unsigned integers as compared to the ranges of values of the corresponding signed types? Does it specify the semantics of assigning negative values to unsigned integers? If so, perhaps the current recommendation is acceptable. If not, the ISO_C_KINDS module may be dependent upon unsigned types becoming part of the language. o The handling of C character strings needs to be clearly specified. o Restrictions on interfaces to procedures written in C need to be specified. For example, is the INTENT attribute permitted, what kinds of s are permitted for dummy array arguments, is the POINTER attribute permitted, are asterisks permitted to appear as dummy arguments, what are the restrictions on function results, are dummy functions permitted? o Details on the restrictions placed upon procedures written in C need to be clearly specified. For example, are they permitted to save pointers to dummy arguments and modify them on subsequent calls to C procedures? o Lack of support for enums is of concern. o No support for stdargs is specified. A synopsis of 95-295 -------------------- 95-295 takes the view that the processor should handle conversions between the Fortran types and the C basic types, including performing array transposition. The EXTRINSIC mechanism (which had already been defined by HPF) is proposed to mark procedures which are written in C. An EXTERNAL_NAME clause is specified on the function or subroutine statement of an interface body in order to specify the name the procedure is given in the C code, which may contain both upper and lower case characters. A MAP_TO attribute is proposed to handle the problem of translating Fortran types to C types. The syntax is MAP_TO(C_TYPE=[, LAYOUT=]). For example, INTERFACE EXTRINSIC(C) FUNCTION IFUNC(A, B) EXTERNAL_NAME('IFunc') INTEGER, MAP_TO(C_TYPE=SHORT) :: A INTEGER, MAP_TO(C_TYPE=LONG, LAYOUT=C_ARRAY) :: B(100, 10) END FUNCTION IFUNC END INTERFACE The possible s are: NO_CHANGE, INT, LONG, SHORT, CHAR, FLOAT, DOUBLE, LONG_DOUBLE, POINTER and CHAR_PTR. CHAR_PTR is used to map Fortran characters objects to C, null-terminated character strings. In addition, a new data type, C_VOID_PTR is proposed. In calls to EXTRINSIC(C) procedures, the '@' symbol is used to indicate that the address of an object is to be associated with an object of a C pointer type. More than one '@' is used to pass pointers to pointers. The proposal then goes on to describe how types other than the basic types can be handled: (i) structs are handled by the user. (ii) Unsigned data is handled via the integer data type in Fortran. (iii) Bitfields are not handled. (iv) char * is handled with the CHAR_PTR mapping. A NULL is added by the processor upon the call, and removed upon return. (v) enums are left as implementation dependent. (vi) unions are handled through derived types whose size is equal to the size of the largest part of the union. The user is responsible for any padding. (vii) Pointers are handled through the '@' symbol. Technical notes on 95-295 ------------------------- X3J3 concurs with the idea of using the EXTRINSIC mechanism coupled with the EXTERNAL_NAME clause (or some similar mechanism of specifying the name). X3J3 has the following technical concerns about the HPF interoperability proposal: o The MAP_TO facility requires more compiler mechanisms than would be required by simply matching Fortran intrinsic data types and kinds with C basic types. In addition, the proposal does not specify how the mappings to structs are to be specified. o X3J3 is not convinced of the requirement for a LAYOUT= clause. o It is not clear whether a processor can claim to conform to this TR if it does not support lower case characters. o It is not clear where the NULL character is to be added to Fortran character objects in mapping to char *. Is it inserted prior to trailing blanks, in place of the last character, or concatenated after the last character? o There is no facility for mapping COMMON to extern variables. o Restrictions on interfaces to procedures written in C need to be specified. For example, is the INTENT attribute permitted, what kinds of s are permitted for dummy array arguments, is the POINTER attribute permitted, are asterisks permitted to appear as dummy arguments, what are the restrictions on function results, are dummy functions permitted? o Details on the restrictions placed upon procedures written in C need to be clearly specified. For example, are they permitted to save pointers to dummy arguments and modify them on subsequent calls to C procedures? o If an actual argument of an EXTRINSIC(C) procedure is @@P, may the procedure modify *P? o Lack of support for enums is of concern. o No support for stdargs is specified. Summary ------- Both proposals are very preliminary: the answers to many significant technical questions are unclear; interactions with major features of C, such as structs and enums are unspecified; the semantics of the existence of C pointers with unrestricted aliasing are not clearly specified. It is not clear whether the aim is to produce a fully general facility for providing interfaces to C procedures in Fortran, or to produce some subset of such a facility, to help some users of Fortran, with the understanding that a general facility will be produced in the Fortran 2000 time frame. The goals of this TR need to be more clearly specified. The problem of the existence of masses of C header files is unsolved. Even if a fully general, portable method of providing interfaces to C procedures in Fortran is specified, writing such interfaces may prove to be a labourious process. Although X3J3 feels that interoperability is an extremely important topic for Fortran, there is some concern about the size of the task. Deciding ahead of time how much of the problem is to be solved by this TR is of great importance. In addition, ensuring that the proposed solution will be naturally extensible to support more (or perhaps all) of C's data types, and possibly even extensible to other languages, such as C++, is vital.