X3J3/96-106R1

     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 <function-stmt> or the <subroutine-stmt>.  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.

     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 <lang-keyword> 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.

     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.