From rz48@rz.uni-karlsruhe.de Wed Oct 25 20:23:55 1995 Received: from eunet.EU.net (eunet.EU.net [192.16.202.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA09761 for ; Wed, 25 Oct 1995 20:23:53 +0100 Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by eunet.EU.net (8.7.1/8.6.10) with ESMTP id SAA06839 for ; Wed, 25 Oct 1995 18:02:46 +0100 (MET) Received: from ry70.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Wed, 25 Oct 1995 17:02:59 +0100 Received: by ry70.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA118076978; Wed, 25 Oct 1995 17:02:58 +0100 Subject: Comments on N1131 (Interop TR) To: sc22wg5@dkuug.dk Date: Wed, 25 Oct 1995 17:02:57 +0100 (CET) From: hennecke@rz.uni-karlsruhe.de X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <"nz11.rz.un.360:25.10.95.16.03.04"@rz.uni-karlsruhe.de> Although it is a bit late to change N1131, here are some comments on it: 2. Scope: The scope of the TR specified in N1131 is "To define language facilities that will permit Fortran procedures to call C procedures." o There is no reason why C procedures should not be callable from a
, so perhaps "Fortran " is more adequate than "Fortran ". o To guarantee proper interoperability with C, there must be a way to access global data objects of C, which can be easily mapped to COMMON blocks (if the name binding problem (case, length) is solved, but that has to be done for procedures anyway). 3. Purpose and justification: There has been much talk about Fortran accessing a GUI written in C (X-windows, Motif, ...), this is mentioned here as a justification for the TR. But there are some fundamental problems which, imho, cannot be solved by the proposed TR alone. One should not expect too much in this area: even with a perfectly sound interlanguage calling mechanism, a huge amount of native Fortran must be written to use a C GUI portably. For example X11 consists of two very different parts: the compiled library (a collection of object files, whose external symbols can be mapped to F95 (``somehow'')) and a collection of C header files. These are much too complex to be automatically dealt with. They hold: o Type definitions These can, ``somehow'', be mapped to F95. But it is non-portable to use the X11 type components directly. These types can be thougt of as having the PRIVATE attribute (although they haven't, their components are just not documented in the manuals...). And even the one-to-one mappings may become awfully complicated because of C #typedef# mechanisms that may cause tricky aliasing effects: types defined in the manual should be retained, those that are not should be ``de-referenced'' to documented (or intrinsic) ones... o Named constants In C header files, named constants are generally _not_ established as global data objects having the #const# qualifier (this would match a F95 object having the PARAMETER attribute), but as preprocessor directives that ##define# a value for a token. This is substituted by the C preprocessor, and does not map to anything in F95. On the other hand, these named constants are required to gain the desired portability. Their values are not defined in X11. o Macros emulating procedures What seems to be a C #extern# procedure need not necessarily be one: C has a macro facility built in its preprocessor which is used to implement many ``functions'' as macros. It is impossible to define a binding to such macros because they are resolved to C source text during preprocessing of C source that uses the macro. Often the standard docs just don't specify if a ``function'' is a true function or is a macro. Example: Even the ISO C ``intrinsic'' functions getc() and putc() are often implemented as macros that in turn call fgetc() and fputc()! But they may as well be functions. So there seems to be no way around building F95 MODULEs that model the corresponding C header files, and introduce PARAMETERs, TYPEs and procedures that implement the C macro ``functions''. It may well be expected that this has to be done mostly by hand... Needless to say that these pessimistic comments are not intended as a vote _against_ the interoperability TR. I just felt that the purpose defined in N1131 is a bit too optimistic. Getting a proper calling interface to compiled C code _is_ a crucial prerequisite, and does suffice for applications that do not use header files excessively. Best regards, Michael ====================================================================== Michael Hennecke http://www.uni-karlsruhe.de/~Michael.Hennecke/ ---------------------------------------------------------------------- University of Karlsruhe RFC822: hennecke@rz.uni-karlsruhe.de Computing Center (G20.21 R210) BITNET: RZ48@DKAUNI2.BITNET Zirkel 2 * P.O. Box 69 80 Phone: +49 721 608-4862 D-76128 Karlsruhe Fax: +49 721 32550 ======================================================================