J3/03-128

To: J3
From: UK Fortran panel
Subject: Edits for UK comments MTC12-MTC15  (C Interoperability)
Date: 10 March 2003


Comment MTC12 of the UK vote was:

MTC12 Make TYPE(C_PTR) be an opaque derived type

    TYPE(C_PTR) should be required to be an opaque derived type. Allowing
    it to be an (alias for) integer invites unreliable programming
    practices.

We also submitted comment TC8, remove the TYPEALIAS facility.  If this
comment is accepted, then MTC12 is automatically accepted as a
side-effect.

If TYPEALIAS is retained, the edit to make this (MTC12) change is:

386:2.  Delete " or shall be a type alias name".

_________________________________________________________________

Comment MTC13 of the UK vote was:

MTC13 Require the prototype of an interoperable C function not to have
    the inline function specifier

    This is needed to remove possible linkage difficulties

    A possible edit is the following:
    Page 389:18+. Add:
    (7) The C function prototype does not have the inline function
    specifier.

The edits for this are:
389:17. Delete line.
389:18. Change  ")."  to  "); and".
389:18+. Insert
  "(7) the C function prototype does not have the inline function
specifier."
_________________________________________________________________

Comment MTC14 of the UK vote was:

MTC14 Add further requirement for C interoperability

    Certain aspects of C interoperability have not been addressed: the
    following additional requirements appear to be needed:

    A C procedure shall not:
    (1) invoke longjmp where this would imply leaving an active Fortran
        procedure.
    (2) use signal (C std, 7.14.1) to change the handling of any exception
        that occurs in a Fortran routine or which is being handled by the
        Fortran processor.
    (3) perform i/o to a file that is currently connected to a Fortran
        unit, if a Fortran procedure has performed or will perform i/o
        to that unit.
    (4) close a file that is currently connected to a Fortran unit.
    (5) alter the floating-point status other than by setting an
        exception flag to signalling.

    If a C procedure reads the floating-point exception flags on entry,
    the result is processor-dependent.

The edits for this are:

360:3+ (in Note 14.7).  Delete "No such requirements can be placed on
procedures defined by means other than Fortran.  For such procedures, it
is the responsibility of the user to ensure that the floating point
status is preserved."

{The first of these statements in Note 14.7 is factually incorrect.
There are other requirements placed on procedures defined by means other
than Fortran, ***when they are part of a Fortran program***.  For
example, [392:23-25] "If a procedure defined by means other than Fortran
invokes setjmp or longjmp, that procedure shall not..."

Like restrictions on array element accessing, such requirements are all
requirements on the programmer, not a requirement on the processor.
That does not make them any less a requirement!}

393:0+ (after Note 15.25).  Add two new sections:

<<15.5 Interoperation with exceptions and IEEE arithmetic procedures>>

A procedure defined by means other than Fortran shall not use signal (C
standard, 7.14.1) to change the handling of any exception that occurs in
a Fortran procedure or which is being handled by the Fortran processor.

A procedure defined by means other than Fortran shall not alter the
floating-point status (14.5) other than by setting an exception flag to
signalling.  {Ref the deletion in Note 14.7}

If a procedure defined by means other than Fortran reads the
floating-point exception flags on entry, the result is
processor-dependent.


<<15.6 Interoperation with C input/output>>

If a file is currently connected to a Fortran unit and a Fortran
procedure has executed any input/output statement other than INQUIRE on
that unit, a procedure defined by means other than Fortran shall not
perform input/output to or from the file.

If a procedure defined by means other than Fortran has performed
input/output to or from a file, a Fortran procedure shall not
execute any input/output statement other than INQUIRE on a unit that is
connected to that file.

A procedure defined by means other than Fortran shall not close a file
that is currently connected to a Fortran unit.
_________________________________________________________________

Comment MTC15 of the UK vote was:

MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should
    not depend on the rounding mode used for arithmetic

    It appears that there are no requirements on the
"PROCESSOR_DEPENDENT"
    i/o rounding mode, so this could vary depending on the rounding mode
    used for arithmetic.  That would be unfortunate and confusing.
    Suggested edit:
    Page 229:10
    Change "other modes" to "other modes, and is not affected by the
    rounding mode used for arithmetic (14.3)".

We endorse the edit suggested in the original vote.