[MPI3 Fortran] Derived-data, a new/late comment on Fortran WG5 ballot N1846

[Bader, Reinhold]

Hello all, 

 with respect to "Problem A" I have the following (preliminary, given my state of knowledge) opinion:

Given the standard's *present* provisions (which makes an explicit formal distinction between SEQUENCE and BIND(C))
an implementation wishing to provide C interop faces the following situation:

(1)  SEQUENCE types with interoperable ultimate components have the same storage layout as BIND(C) types of the same structure
(2) SEQUENCE types do not have the same storage layout as said BIND(C) types

In case (1), an implementation may be liberal and accept (like e.g., ifort does) non-conforming code. The latter may involve
SEQUENCE actual arguments in BIND(C) calls, or BIND(C) type components in SEQUENCE types, or SEQUENCE components in BIND(C) types.
 
In case (2), the implementation has no choice but to strictly follow the standard's provisions, and reject any attempt to intermix
SEQUENCE with BIND(C). 

I don't know which implementations are of class (2), but any attempt to make use of SEQUENCE legal with BIND(C) via the TR would 
need to exclude such implementations. The only thing that could conceivably be done for such implementations is to allow SEQUENCE 
types as (non-VALUE) actual arguments in BIND(C) interfaces, and require that the corresponding C prototype is a void *. This would 
then on the C side force a programming style like

typedef struct {
  ...
} mytype;

#ifdef CFI_SEQUENCE_MATCHES_C
    void foo(mytype *obj) {
         // reference obj via type components
    }
#else
   void foo(void *obj) {
        // reference obj components via accessors which must be written in Fortran
  }
#endif


Regards
Reinhold

> -----Ursprüngliche Nachricht-----
> Von: Rolf Rabenseifner [mailto:rabenseifner at hlrs.de]
> Gesendet: Donnerstag, 14. April 2011 16:23
> An: John Reid; interop-tr at j3-fortran.org
> Cc: Bader, Reinhold; Craig Rasmussen; Bill Long; N.M. Maclaren; Jeff Squyres;
> MPI-3 Fortran working group
> Betreff: Derived-data, a new/late comment on Fortran WG5 ballot N1846
> 
> Dear John, dear members of the WG5 and J3 Fortran committees,
> 
> I'm sorry that with this additional comment on problems regarding derived
> types, I missed the deadline of the N1846 ballot for the N1845 draft of the TR
> 29113 on extensions on Fortran-C interoperability.
> 
> It looks like that there are two problems with derived types and the Fortran-
> MPI-compatibility with a background in the Fortran-C-interoperability.
> 
> Problem A: Sequence derived types in the MPI routine
>            interfaces, which are declared with BIND(C);
>            this problem occurs with the new MPI handles
>            and MPI statuses.
> 
> Problem B: Derived type, SEQUENCE derived type, and
>            BIND(C) derived type as actual user buffers
>            for TYPE(*),DIMENSION(..) dummy arguments
>            in BIND(C) MPI routine interfaces.
> 
> Problem C: Based on problem B we have the question
>            whether the new TYPE(*),DIMENSION(..) dummy
>            arguments in BIND(C) MPI routine interfaces
>            really allow all actual arguments that were
>            possible with implicit interfaces or with
>            explicit interfaces in combination with
>            pragmas like
>              !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf
>            and
>              !$PRAGMA IGNORE_TKR buf
>