J3/00-269

 To:       J3
 From:     John Reid
 Date:     23-August-2000
 Subject:  Unresolved technical issues of C-Fortran interoperability

 Here is a copy of N1402, which was prepared by WG5 at Oulu
 in the hope of aiding the work of J3.

 .................................................................

                                         ISO/IEC JTC1/SC22/WG5/N14O2

        UNRESOLVED TECHNICAL ISSUES OF C-FORTRAN INTEROPERABILITY

                      Matthijs van Waveren

 All references are to the 00-007r2 F2K draft document.

 1. Rounding mode

 The F2K draft states (page 364):

 "In a procedure other than IEEE_SET_ROUNDING_MODE, the processor shall
 not change the rounding mode on entry, and on return shall ensure that
 the rounding mode is the same as it was on entry."

 The preceding specifies that a Fortran subprogram must restore the
 rounding mode that was in effect on entry to the subprogram prior to
 returning to its caller. Because IEEE_SET_ROUNDING_MODE is the only
 procedure defined by this standard that affects the rounding mode, a
 processor need only check whether a call to IEEE_SET_ROUNDING_MODE
 appeared in the subprogram in order to determine whether it is
 necessary to save the rounding mode on entry and restore it on return.

 A call to a C function might affect the rounding mode. How is a Fortran
 processor to deal with the preceding requirement in light of that fact?
 If it saves and restores the rounding mode around every call to a C
 procedure, that will destroy the performance of the program. The
 standard could require that a C function called from Fortran obey this
 same rule, since the Fortran processor itself cant conveniently enforce
 the rule.

 Straw Vote:

 Should F2K keep the restriction for the case of C function calls (in
 which case there could be a performance penalty), or should the
 restriction be relaxed ?

 Keep the restriction for C function calls     4
 Relax the restriction for C function calls    7
 Undecided                                     4

 2. Pointers

 Fortran 95 has the functionality of finding out whether a pointer is
 associated with its target or not. This is implemented with the
 intrinsic function ASSOCIATED.

 J3 needs guidance on how to implement this functionality for objects of
 type C_PTR (see issue 252 on page 386). This can be done in two ways:

 1. Specify an intrinsic procedure, which compares two objects of type
 C_PTR, and returns the value .TRUE. if the two objects are the same,
 and .FALSE., if the two objects are different. Specify a constant of
 type C_PTR, which corresponds to the (null) pointer (for instance
 C_NULL_PTR). This constant can be used as argument in the intrinsic
 procedure.

 2. Allow comparison with .EQ. of objects of type C_PTR, and define a
 constant of type C_PTR, which corresponds to the (null) pointer (for
 instance with name C_NULL_PTR). This solution has the drawback that, if
 the C_PTR is a type alias which maps to an INTEGER type, comparison to
 an INTEGER constant becomes possible, and pointer arithmetic might be
 come possible.

 Straw Vote #1:

 What should be the requirement of the intrinsic function:

 Test against C_NULL_PTR only    1
 Test against pointer equality  13
 Undecided                       1

 Straw Vote #2:

 Which language specification should J3 use:

 Specify an intrinsic procedure  14
 Extend the .EQ. operator         0
 Undecided                        1

 3. Additional Kind Type Parameters

 Sections 7.17 and 7.18 of the C99 standard define a number of C type
 definitions for integers of various sizes. These type definitions are
 intended to facilitate portability between C implementations. No
 corresponding Fortran kind type parameters are defined in the C
 interoperability chapter.

 J3 needs guidance on whether or not additional kind type parameters
 should be added to facilitate portable interoperation with C99 (see
 issue 251 on page 385). This would not add much new functionality to
 Fortran and would add a lot of text to the Fortran standard. However it
 would assist in portable interoperability, especially between machines
 with strange integer sizes (e.g., Cray vector, DSP).

 Straw vote:

 Should J3 add additional kind type parameters to Fortran ?

 All additional kind type parameter  0
 Only the size_t integer type       11
 None                                0
 Undecided                           4