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