[MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind

[N.M. Maclaren]

I am responding to this shorter list because I find it less confusing.

>The complete list of dummy argument types is:
>
>TYPE(*), DIMENSION(..), ASYNCHRONOUS  [checked above]
>TYPE(*), DIMENSION(..)

No problem, but it does need TS 29113.

>INTEGER  [checked above]
>INTEGER, ASYNCHRONOUS
>INTEGER, DIMENSION(1)
>
>INTEGER(KIND=MPI_OFFSET_KIND)   [checked above]
>INTEGER(KIND=MPI_ADDRESS_KIND)  [checked above]
>INTEGER(KIND=MPI_ADDRESS_KIND), ASYNCHRONOUS
>INTEGER(KIND=MPI_COUNT_KIND)

See (A) below.

>INTEGER, OPTIONAL  [checked above]

No further problem, but it does need TS 29113.

>LOGICAL  [checked above]

Gug.  See (B) below.

>CHARACTER(LEN=*)  [checked above]

No further problem, but it does need TS 29113.

>CHARACTER(LEN=MPI_MAX_ERROR_STRING)
>
>CHARACTER(LEN=valuelen) ! with valuelen being another dummy argument

See (C) below.

>TYPE(C_PTR), VALUE  [checked above]
>TYPE(C_PTR)

No problem.

>TYPE(MPI_Comm)  [checked above]
>TYPE(MPI_Comm), ASYNCHRONOUS

See (D) below.

>TYPE(MPI_Status)  [checked above]

See (E) below.


This assumes that BIND(C) is specified on the procedures; if it is not,
implementations may have to provide wrappers, in which case all of these
problems disappear.  The difficulties are caused SOLELY by the desire to
use the same functions for both.

I don't see how that will work, anyway, as BIND(C) passes all non-VALUE
arguments as addresses, and the C interfaces define a lot of them as
values.  Communicators are one example, but they are used in almost all
of the calls.

    A) Default INTEGER is, as you say, supported only if it maps to some
C integer type.  Because of the attempt to keep the same interfaces for
Fortran and C, I would be chary about a system where KIND(0) was not
equal to C_INT, but that will be the dominating case.

    B) There is no match between Fortran default LOGICAL and anything in
C.  INTEGER(C_INT) has the right storage and wrong semantics;
LOGICAL(C_BOOL) has the right semantics and wrong storage.
LOGICAL(C_BOOL) is defined to interoperate with _Bool, but I wouldn't
trust it an inch.  If it is never passed as VALUE, it will probably be
OK, but I wouldn't bet on it.

Some C compilers will almost certainly quietly convert it to int in
arguments and results, with a kludge to make sizeof() and the unary '&'
operator work.  Quite a lot have done (still do?) that with integers
shorter than int and reals shorter that double, to help with K&R
compatibility.  If the Fortran compiler does the same, you are OK,
but I have seen nasty problems here.

I don't see any practical option but to have non-BIND(C) wrappers.

    C) Default CHARACTER is supported only if KIND(' ') is equal to
C_CHAR.  However, that will almost certainly be the case.

    D) These are opaque types, and I don't see a problem.

    E) I don't see a particular problem, though don't even think of
mapping Fortran derived types to C structures unless they are BIND(C)!
Interoperating between two C compilers is bad enough :-(


Regards,
Nick Maclaren.