[MPI3 Fortran] MPI_INIT issues

[Malcolm Cohen]

Bill Long wrote:
>In terms of the interface, I think I would prefer just making MPI_Init 
>effectively generic, with the allow calls:
>
>   integer :: ierror
>   character(:),allocatable :: args(:)
>
>
>   call MPI_Init( )            ! Existing form
>   call MPI_Init (ierror)  ! Existing form including optional status
>
>   call MPI_Init (args)    ! New form
>
>   call MPI_Init (args,ierror)  ! New form with the optional status argument.
>
>Both arguments are INTENT(OUT). The array arg is allocated inside MPI_Init with 
>a length parameter equal to the maximum length of the arguments or the command. 
>The bounds are 0:nargs.  On return arg(0) would be the command text, and 
>arg(i:ubound(arg),1)) would be the arguments.  The number of arguments is 
>size(arg)-1.  [Redundantly, the number of arguments could be returned as 
>another argument.]

This is reasonable but does not allow the program to detect trailing blanks on 
an argument.  It might be argued that this is not important for the MPI 
community, but it is a limitation.

I would tweak the above suggestion to 2 forms:
  MPI_INIT( [ ierror ] )
  MPI_INIT( args [ , ierror ] )
i.e. allow ierror to be an absent optional dummy argument.

If we want to be able to handle trailing blanks, then replacing 
MPI_GET_COMMAND_ARGUMENT with

  SUBROUTINE mpi_getarg(n,arg,ierror)
    INTEGER,INTENT(IN) :: n
    CHARACTER(:),ALLOCATABLE,INTENT(OUT) :: arg
    INTEGER,INTENT(OUT),OPTIONAL :: ierror

would be better than just copying the F2003 interface (which took a *very* 
conservative view - justified at the time, but that was approx a decade ago). 
Avoids all the arguments about length, handles trailing blanks properly, avoids 
the user mucking around with allocating stuff himself, avoids the common 
situation where the programmer decides that (e.g.) 80 characters is long enough 
and doesn't bother with handling the length properly at all - until several 
years later when someone else complains that it doesn't work on his system 
because his filenames are longer.

If that route is taken, I would definitely pick something short like MPI_GETARG 
for the name: we're not copying the standard's interface so no reason whatsoever 
to copy the name.

For that matter if we have a separate "nargs" enquiry rather than Bill's 
suggestion, changing MPI_COMMAND_ARGUMENT_COUNT to MPI_IARGC or similar would be 
reasonable; the standard names for these are really rather excessively long.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.