OK, sorry I should have done this earlier! I just had a look into openmpi, and how it's done there, and found, that there already assumed size is used. Looking at the standard I found it is also everywhere talking of assumed size only. For example in openmpi-1.2.5/ompi/mpi/f90/mpi_buffer_attach_f90.f90.sh a construct like this is used: for rank in $allranks do case "$rank" in 0) dim='' ; esac case "$rank" in 1) dim=', dimension(*)' ; esac case "$rank" in 2) dim=', dimension(1,*)' ; esac case "$rank" in 3) dim=', dimension(1,1,*)' ; esac case "$rank" in 4) dim=', dimension(1,1,1,*)' ; esac case "$rank" in 5) dim=', dimension(1,1,1,1,*)' ; esac case "$rank" in 6) dim=', dimension(1,1,1,1,1,*)' ; esac case "$rank" in 7) dim=', dimension(1,1,1,1,1,1,*)' ; esac The only 2 meaningful options are the first two. $rank = 0 provides the possibility to provide the routine with a scalar. $rank = 1 enables the routine to take an array of any rank. The rest is just not needed. At least to my understanding. I would even doubt, that the first option is really necessary, as the standard states buffer for MPI_BUFFER_ATTACH to be: <type> BUFFER(*) To my reading that would mean it has to be an array. From the options above $rank = 1 would then be the only one, that is really needed. The MPI-2 standard is talking about this issue on page 285 in the paragraph "Problems Due to Strong Typing". As I read it, it is expected to only use the array. The user can always just use an array of size 1. However it is very convenient to just put the scalar in the argument list ;) So it certainly is a nice thing to have the additional interface (but requires to double the work by the implementor). Actually you could even an explicit shape array: subroutine MPI_BUFFER_ATTACH(buffer, size, ierror) integer :: size, iError integer :: buffer(size) end subroutine MPI_BUFFER_ATTACH and call it with any integer array, that fits into size. Just try it with the sample program I sent in my first mail ;). This would ensure that the actual argument for buffer isn't larger than size. Regarding the functions with two choice parameters: Is there any function which actually would make it necessary to allow two different types? By a brief glance at the standard, I only found constructs like in MPI_Allreduce: MPI_ALLREDUCE(sendbuf, recvbuf, count, datatype, op, comm, ierror) <type> sendbuf(*), recvbuf(*) integer count, datatype, op, comm, ierror To my understanding this means, that sendbuf and recvbuf have to of the same type. It won't make any sense in the programs logic otherwise anyway. If they are really allowed to be of different types, I would expect them to be on two lines: <type> sendbuf(*) <type> recvbuf(*) But perhaps that's just a bad interpretation by me. No Fortran program should want to get different typed values then it sent. Are there really any MPI functions, where it is sensible to use two different types for the two choice parameters? Otherwise a thousand interfaces would be sufficient (just one logical from your list: 12*75 = 900, all logicals from your list: 15*75 = 1125) for the current MPI-Standard, as it is. Maybe a clarification could be useful for the case of two choice parameters, but maybe this is already clearly specified in the standard somewhere. Kind regards, Harald -- Dipl.-Ing. Harald Klimach email: [email protected] HLRS, Uni Stuttgart http://www.hlrs.de/people/klimach Nobelstraße 19 phone: 0711-685 60300 70569 Stuttgart fax: 0711-685 65832