(j3.2006) (SC22WG5.4492) Ballot on N1866

[Robert Corbett]

                        WG5 letter ballot on N1866
                        John Reid, 7 July 2011

This is the letter ballot that WG5 agreed to hold on the draft PDTR for
further interoperability of Fortran with C. It has been constructed by
the editor Bill Long following the recent WG5 meeting, see Resolution G7
in N1861. He has documented the changes from N1854 in N1865.

Please answer the following question "Is N1866 ready for forwarding to SC22
as the PDTR?" in one of these ways.

        1) Yes.

        2) Yes, but I recommend the following changes.

        3) No, for the following reasons.

        4) Abstain.

---------------------------

I vote

        3) No, for the following reasons.

Before giving my reasons for voting no, I want to say
that the current draft is much better than the draft
produced at the February meeting.

Robert Corbett
representing Oracle America

----------------------------

1.  The specification of the extended usage of the
    ASYNCHRONOUS attribute given in Clause 2.4 puts
    new restrictions on programs, but does not put
    new restrictions on processors.  I believe that
    new restrictions on processors were intended,
    but they are not stated.  A statement should be
    added to the effect that the value of a pending
    communication affector should be regarded as
    being defined or redefined by execution of an
    asynchronous communication completion procedure.

2.  The specification of the function CFI_allocate
    states that "dv shall point to a C descriptor
    describing the object."  I assume that the
    object to which that statement refers is the
    object to be allocated.  I presume that members
    base_addr, elem_len, and dim need not describe
    the object being allocated before the call of
    CFI_allocate is successfully completed.  The
    specification of CFI_allocate should state
    which fields of the C descriptor must be valid
    before CFI_allocate is called.

    The description of CFI_allocate should state
    which members of the C descriptor referenced by
    dv are updated if the allocation is successful.

3.  The description of CFI_deallocate should state
    which members of the C descriptor referenced by dv
    are updated.  My guess is that only the member
    base_addr needs to be updated.  A processor might
    also be allowed to update the members elem_len
    and dim.

4.  The macro CFI_MAX_RANK assumes that processors
    have fixed maximum ranks.  That might be true of
    all modern Fortran processors.  However, I have
    used older compilers that imposed no fixed limit
    on the rank of arrays.  I propose that the macro
    CFI_MAX_RANK be left undefined if the processor
    has no fixed limit on the rank of arrays.

5.  The definition of the type CFI_index_t is not a
    good choice.  I have used compilers on machines
    with 16-bit address spaces that allowed array
    bounds in the range of 32-bit signed integers.
    I have used compilers on 32-bit machines that
    allowed array bounds in the range of 64-bit
    signed integers.  The definition of the type
    CFI_index_t should be a signed integer type
    capable of representing the lower bound of an
    array in the Fortran processor.

6.  The type of the member extent of the C structure
    type CFI_dim_t should be an unsigned integer type
    that is at least as large as a size_t.  I propose
    that the value of dim[r-1].extent for a rank r
    assumed-size array be the maximum value of that
    unsigned integer type.

7.  The type of member sm of the C structure type
    CFI_dim_t should be a signed integer type that is
    at least as large as a ptrdiff_t.

8.  The DPTR should simply state what the correspondence
    is between the elements of the member dim of the
    C structure type CFI_cdesc_t and the order of Fortran
    bounds and subscripts.  Paragraph 3 of Clause 5.3.3
    forces the order to be column major, but not in a way
    that is easily understood.

9.  The prohibition against explicit-shape arrays of class
    TYPE(*) is harmful.  Regardless of Note 2.1, there is
    a functional difference between an explicit-shape
    array of class TYPE(*) and an assumed-size array of
    class TYPE(*).  Consider the following code fragment

      SUBROUTINE CALLER(P)
        INTEGER, POINTER :: P(:)
        INTERFACE
          SUBROUTINE CALLEE(A) BIND(C)
            TYPE(*), DIMENSION(9) :: A
          END SUBROUTINE
        END INTERFACE

        CALL CALLEE(P)

      END

    One implementation of the call of CALLEE would make
    copy of the first nine elements of the array
    referenced by P before the call and copy the elements
    back after the call.  If the array A were assumed-size,
    a similar implementation would need to make a copy of
    the entire array referenced by P.

10. The definition of "assumed-type object" given in
    Clause 1.3.2 is deficient.  It does not match the
    definition given in Clause 2.1.  At the very least,
    it should say

        <dummy variable> whose dynamic type and type
        parameters are assumed from its effective
        argument

11. The use of the term "struct" throughout the DPTR is a
    bit jarring.  The C standard uses the full word
    "structure."