Good point. This is now fixed in the dynamic chapter.
In a brief glance through the document this looks like the
only place where it was wrong.
> 2. Fortran90/95 elements are used in some places (KIND=, ! for comments,
> DO/END DO, ...). It would be a significant improvement for people
> concerned about Fortran90/95 bindings if the INTENT attribute would
> also be used in the specification of the Fortran bindings. This does
> not solve the <choice>-type and other problems, but would be a good
> first step (and easy to ignore for FORTRAN77-ers). The attribute comes
> in three forms, INTENT(IN|OUT|INOUT), and should be easily derived from
> the language-independent specs. Lots of typing, of course, and a separate
> section for corresponding MPI 1.1 Fortran interfaces might be necessary...
The warrants further discussion.
It seems like basically a good idea, but I'm not sure how to
handle some details.
1. Do we now need to specify separate F77 and F90 bindings?
2. Am I correct that these functions now require explicit interfaces
and therefore would require using the mpi module?
3. For routines with choice arguments, do we just leave out
the intent information?
A related change would be to use assumed-shape arrays rather
than assumed-size arrays for dummy arguments. This
seems to involve the same issues.
> 3. page 9:34+ says:
> "Discussion: Did we want 30 or 31?
> Assume upper limit is 32 and need 1 for profiling??"
> Fortran90/95 only guarantees 31 characters in a name, minus one for
> profiling means I would advocate THIRTY significant characters.
Sounds good.
>
> 4. page 72:44 talks about "``true'' (C-like, Cray-like) pointers".
> I would resist calling Fortran90/95 pointers ``wrong'' pointers,
> since there is a law (ISO/IEC 1539) which defines them to be
> ``true'' pointers, too. ``true ( )'' should be deleted from MPI-2.
Agreed.
>
> 5. I would like to see the following problems in MPI 1.1 fixed as part of
> MPI 1.2 (references are to MPI 1.1, 12-June-95, with changebars):
>
> page 122:1 and 215:8
> Change "FUNCTION USER_FUNCTION( INVEC(*), INOUTVEC(*), LEN, TYPE)"
> to "SUBROUTINE USER_FUNCTION(INVEC, INOUTVEC, LEN, TYPE)"
> to have the correct classification (I think) as a subroutine,
> and to make the dummy arg declarations correct Fortran.
>
> page 170:5+ and 170:46+
> The INTENT of the arguments of the Fortran declarations should be given.
> For the main MPI procedures, intent may be derived from the language-
> independent specs, but not for these dummy procedures.
>
> page 215:13 and 215:21
> Change "PROCEDURE" to "SUBROUTINE", just to make it FORTRAN.
>
> page 215:23
> There is no Fortran example for a Handler_Function. It should.
I don't have an MPI 1.1 spec in front of me, but I do remember the
first example quite clearly. I intended to request that this be added
to MPI 1.2. Rusty, do we still have an opportunity to add these
to the list of minor corrections?
> 6. Minor fixes in MPI-2:
>
The page numbers you give here don't correspond to
my January draft. Could you give a little more context for the
location?
> PS: ISO's Fortran/C interoperability project mentioned on page 335:45
> will probably forward its current draft to the first round of ballots
> in March 1997. I'm the project editor, and will write up a summary
> of what can and can't be done for MPI bindings, using that standard.
> I'll let MPIF know when (and where) this write-up will be available...
Again, the reference doesn't correspond to my text. What chapter/section
is this in?
Thanks for the comments.
Bill