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

[Craig Rasmussen]

I've commented on a few of Nick's points below:

On Mar 1, 2013, at 1:20 PM, N.M. Maclaren wrote:

> 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.

This can be handled in the wrapper.  Anyone who uses the PMPI interfaces in C will have to take this into account with a typecast (or equivalent means).

> 
>   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.

Nick, can't the wrapper C code safely cast to an integer (or simple assignment after testing for true/false) from a _Bool?

To remove BIND(C) from the MPI-3 interfaces is practically very difficult to do because of the PMPI interaces.

> 
>   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 :-(
> 

This is necessary anyway because the MPI handles are dummy arguments in BIND(C) interfaces.

-craig