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

[Rolf Rabenseifner]

https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/364#comment:7
shows all 32 routines with CHARACTER arguments.

Can I summarize your analysis to:

- 21 routines CHARACTER(LEN=*),INTENT(IN) arguments 
  
  All these routines need the length information at the callee.
  The non-BIND(C) interface works fine (as in mpif.h and the mpi module)
  A BIND(C) interface would need to be changed, because the length
  information must be passed in an additional argument
  (or as in C by a special terminator character).

- 2 routines with CHARACTER(LEN=*),INTENT(OUT) arguments

  These routines works with non-BIND(C) and BIND(C),
  because the application must provide a string-buffer
  that is large enough. 

- 0 routines with CHARACTER(LEN=SOME_CONST),INTENT(IN) 
- 7 routines with (only) CHARACTER(LEN=SOME_CONST),INTENT(OUT) 

  These routines work with non-BIND(C).
  For BIND(C), we need to change the declaration into
  CHARACTER(LEN=1),DIMENSION(xxx)
  With non-BIND(C), this alternative declaration would 
  also work correctly with any arguments passed
  in the same way as to CHARACTER(LEN=xxx).

  This interface change requires Fortran 2003 compilers.

- and following special cases:
   MPI_Lookup_name
   MPI_Info_get
   MPI_Comm_spawn
   MPI_Comm_spawn_multiple

A shortcut of this summary:

Due to the 22 routines with LEN=*, 
BIND(C) on the MPI API level should be fully removed.
BIND(C) makes sense only on this internal interface,
which should be optional.    

Based on this, the possible options dramatically shrink.

Best regards
Rolf


----- Original Message -----
> From: "Tobias Burnus" <burnus at net-b.de>
> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
> Cc: "MPI-3 Fortran working group" <mpi3-fortran at lists.mpi-forum.org>, longb at cray.com, "Craig Rasmussen"
> <rasmus at cas.uoregon.edu>, "Hubert Ritzdorf" <Hubert.Ritzdorf at emea.nec.com>, "Martin Schulz" <schulzm at llnl.gov>, "Jeff
> Squyres (jsquyres)" <jsquyres at cisco.com>
> Sent: Wednesday, March 27, 2013 11:44:56 PM
> Subject: Re: [MPI3 Fortran] [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
> I restrict myself to replying to Option 4, only, in this email.
> 
> Rolf Rabenseifner wrote:
> > Option 4:
> > (needed for 2c, for all others it is independent)
> > - Substituting in mpi_f08
> >    all CHARACTER(LEN=xxx)
> >    by CHARACTER(LEN=1),DIMENSION(xxx)
> >    with xxx = a fixed constant.
> >
> >    As far as I understand, this cannot be done for CHARACTER(LEN=*)
> >    because otherwise the MPI routine cannot learn about the length
> >    of the string, see, e.g., argv array in MPI_COMM_SPAWN.
> 
> For C interoperability, "character(len=*)" doesn't make sense as with
> Bind(C) just a pointer is passed without any length information (and
> the
> string is also not zero-terminated). With Fortran semantics, one
> either
> passes the length as hidden argument or does not pass the pointer to
> the
> data but some descriptor with the length information. In order to make
> "len=*" work with Bind(C), the information has to be passed in some
> way.
> 
> However, using
> subroutine sub(str, len) Bind(C)
> integer :: len
> character, dimension(len) :: str
> would be one valid replacement - albeit slightly inconvenient.
> (Without
> BIND(C), character(len=len) is also valid but has no advantage to
> len=*.)
> 
> >    Pro: As far as I understand, this is needed for BIND(C) for the
> >         MPI routines that have CHARACTER(LEN=xxx) dummy arguments.
> >    Con: Non-consistent solution for a bug in TS29113 that should be
> >         fixed in TS29113.
> >         The mpi and the mpi_f08 moudlues will be inconsistent to
> >         each other. We do not want to change the old mpi module and
> >         mpif.h Fortran interface.
> 
> Note: For users, both interfaces act exactly in the same way and they
> shouldn't be able to detect the difference. (Unless their compiler
> doesn't support that part of Fortran 2003. But (nearly) all current
> compilers should be able to do so.)
> 
> >         With current CHARACTER(LEN=xxx), the MPI routine can check
> >         at
> >         runtime whether the provided actual argument is long enough.
> >         With CHARACTER(LEN=1),DIMENSION(xxx), such a check is
> >         impossible.
> 
> I fail to see why the diagnostic should be impossible. Compilers are
> doing array bounds checks since ages. If the explicit interface is
> known, compilers can simply insert a check before the function call.
> If
> the interface is not known, it gets more cumbersome but it is also
> possible (e.g. some compiler store in the caller the size of the
> actual
> arguments in a global variable and compare in the callee the values
> with
> the expected sizes).
> 
> The only advantage of len=... is that Fortran semantic implies that
> the
> string length of the actual argument is available to the callee, which
> makes checking simpler. But of one passes a simple "char *" with
> BIND(C), this information is also not available.
> 
> In addition, if the the array sizes are known at compile time and an
> explicit interface is used (or, as here, both are in the same file), a
> compiler can detect the mismatch even at compile time:
> Warning: Actual argument contains too few elements for dummy
> argument 'x' (3/5)
> 
> subroutine foo(x)
> character :: x(5)
> end
> 
> call foo("abc")
> end
> 
> 
> >    Bill and Craig, please correct me if I'm wrong.
> >         Is this bug fixable in TS29113, or is there a reason,
> >         why CHARACTER(LEN=xxx) is not interoperable with C?
> 
> Well, TS29113 cannot be changed as it is not a bug (solvable via an
> interpretation request) and as the TS is published; it would be rather
> something for the next Fortran standard.
> 
> At least if one does not allow assumed-length, there is no real
> fundamental reason to not allow other lengths.
> 
> However, one runs into many inconsistencies and has to deal with a lot
> of special cases. For instance, while "character(len=1), value" and
> "char" are passed in the same way, "character(len=2), value" does not
> match any C type. Assuming, one could use "char[]". But then, passing
> len=1 by value ("char") and len=2 by reference ("char[]") doesn't look
> clean. A "character(len=1)" would be "char *" and "character(len=2)"
> then "char**". But what would be "character(len=n)" - what happens if
> one changes an "integer :: n = 1" to "integer, paramter :: n=1", would
> that change the ABI?
> 
> I think there are too many issues like those to make it very unlikely
> to
> be changed in the next standard. In particular, as using
> character(len=1), dimension(xxx) :: str
> works sufficiently well and it is already implemented in most
> currently
> used compilers. Hence, I believe the standard will only be augmented
> if
> a very strong case can be made that allowing len=1 has large
> advantages.
> (I do not see this happening.)
> 
> Tobias

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)