From rah@SSESCO.com Sun Feb 11 21:39:49 1996 Received: from garbanzo.SSESCO.com (garbanzo.ssesco.com [192.55.187.34]) by dkuug.dk (8.6.12/8.6.12) with SMTP id VAA16703 for ; Sun, 11 Feb 1996 21:39:39 +0100 From: rah@SSESCO.com Received: from chips.ssesco.com by garbanzo.SSESCO.com (AIX 3.2/UCB 5.64/4.03.SSESCO.srv.92.07.22) id AA15892; Sun, 11 Feb 1996 14:39:28 -0600 Received: by chips.SSESCO.com (AIX 3.2/UCB 5.64/4.03.SSESCO.cli.92.10.15) id AA23560; Sun, 11 Feb 1996 14:39:28 -0600 Message-Id: <9602112039.AA23560@chips.SSESCO.com> Subject: X3J3 Liaison report on C interoperability To: sc22wg5@dkuug.dk (wg5) Date: Sun, 11 Feb 1996 14:39:27 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6551 X3J3/96-39 To: WG5, X3J3, Michael Hennecke From: /Parallel Subject: Liaison report on C Interoperability TR References: ISO/IEC JTC1/SC22/WG5 N1174 Jan 8, 1996 X3J3/95-295, X3J3/95-293R1 Date: February 7, 1996 N1174 provides a mechanism for name binding and argument passing for some of the basic data types between a C and Fortran routines. We recognize that the proposal is incomplete at this time. X3J3 concurs that this is an important area, however we have several concerns about the draft. We agree that arrays should not be automatically transposed on a call or return. We do not advocate the MAP_TO approach, we believe users can explicitly do the type conversions if it is inconvenient to use the C types in the rest of the program. 1) The rationale is incomplete. In particular, we believe there should be a clear statement along the lines of "A Fortran routine should be able to call any C routines whose arguments have a general approximation to Fortran data types and should be able to call a series of C routines and pass non-Fortran like arguments between them." Anything significantly weaker than this does not meet the goal in section 2.1. 2) The proposed bind mechanism does not require an explicit interface. It should; we should not extend the external attribute to also specify the C attribute. The interface should also specify attributes of the dummy arguments. 3) There must be a mechanism to handle C extern variables. If the bind syntax is retained we believe it should be strongly considered as the mechanism to "declare" a C extern, rather than relying on providing alternate names for common blocks. Not all implementations are compatible with common blocks and it imposes a naming burden on the user that the compiler can handle. Something like: REAL, (BIND = c_name, LANG = C) :: fortran_name is very similar to the binding syntax proposed for function names. It is the compilers responsibility to figure out how to pass the information on to the linker. 4) We think a compromise between the proposed bind and the HPF EXTRINSIC is reasonable to consider, since EXTRINSIC is likely to become common practice. If the extrinsic is defined as EXTRINSIC ([LANG =] lang-keyword [, [ NAME = ] c_name] ) it provides everything the bind syntax allows. If there is no NAME = clause then the Fortran name is used and it is the users responsibility to pick a correct name. If a NAME= clause is present then there is a renaming. The c_name should not have "leading or trailing underscores" or whatever. It is the processors responsibility to manage name conversion. This would require the processor to pass on the case of the c_name (or Fortran_name) unchanged. The EXTRINSIC spec could be used in an interface block for an external or on a data declaration for a C extern. It may be helpful to note that on a processor where there are multiple C naming/calling conventions, that a processor can extend LANG= to include a particular C compiler by name/version. (It may also be noted that if this facility is eventually extended to C++ that this is a virtual requirement, as name mangling is highly release specific.) 5) Derived types should be considered for those data types that are not strongly Fortran like. This includes enums, c-style pointers, pointers-to-functions. A minimal set of operations, such as succ and pred and the comparison operators for enums, can be defined without introducing the full generality of C pointers into Fortran. 6) Introducing a C-style null-terminated character string should be considered. Perhaps requiring it to have the pointer attribute and build on existing mechanisms for dynamic storage. A minimal set of operators would be needed. 7) A new keyword, perhaps c_sequence (cequence?) should be allowed in a Fortran derived type to require the same layout as in a C struct. Probably with limits such as no Fortran pointers, etc. to prevent passing things which are not well defined on either side of the call. 8) We must be able to pass by reference and by value, with the default being by value. The interface block seems like a better place to specify the reference attribute for an argument than at the call site. Perhaps a %loc attribute; it also needs to be extendable to pointers-to-pointers. 9) A mechanism to support a variable number of arguments, STDARGS, needs to be provided. 10) Although typedefs cannot be handled in general, there should be a discussion of how to treat common cases via kind= and derived types. However, if in F2K, there were to be a statement of the form: typedef FRED is INTEGER then definitions of the form type (FRED) :: x,y,z would allow changes to be accommodated by changing the typedef (e.g. INTEGER to REAL, or more likely INTEGER(0) to INTEGER(8)) The following comments come from a discussion of the proposal at HPFF. 1) The Extrinsic mechanism is useful, and should be used - explicit interfaces are not required for BIND in the TR proposal, which seems like a bad idea 2) Name binding - we'd prefer to see it remain part of the function or subroutine statement, rather than a separate BIND statement - note, both proposals require lower-case letters to be supported by the Fortran processor 3) C extern is a problem for both proposals - COMMON could be implemented on some platforms in a way that does not map to extern 4) The two proposals have very different ways of handling type mapping - TR proposal handles mapping to C data types via KIND - HPFF proposal handles mapping via MAP_TO attribute Weaknesses KIND | MAP_TO ---------------------------------+----------------------------------- - doesn't handle char * or | - completely new argument passing char [] in an easy fashion | machinery - doesn't do array transposition | - doesn't handle structures - Fortran processor has to | - doesn't handle pointers support all kinds corresponding| - doesn't handle typedefs to C types everywhere | - some new machinery is needed to| handle structures | - no handling of pointers | - no handling of typedefs | One point that was made in favor of the MAP_TO is that a user doesn't have to use variables with kind type parameters that correspond to C data types throughout the program. The mapping gets handled at the call through the interface.