[Mpi-forum] MPI_Type_size question

[William Gropp]

The standard doesn't say, but to me, the correct answer would be to  
return an error with class MPI_ERR_OTHER.  This follows the approach  
of providing reliable failure when there is an error, with the user  
able to set ERRORS_RETURN and check for the error.  Returning  
MPI_UNDEFINED allows the casual user to ignore the error, which is not  
the MPI approach to errors.

As to how to fix this, if we insist on backward compatibility, then we  
need new routines, or we need another new type so that we can do the  
same MPI_Count trick (which doesn't fix the problem but lets  
implementations choose between backward compatibility and forward  
compatibility).

Bill

On Jun 18, 2010, at 11:55 AM, Fab Tillier wrote:

> Hi Folks,
>
> Looking at putting together the MPI_Count ticket, I ran across the  
> following issue and was hoping to get some guidance.  Take the  
> following code, using the current int counts, and assume sizeof(int)  
> == 4, sizeof(MPI_DOUBLE) == 8:
>
> {
>   MPI_Datatype myType;
>   MPI_Type_contiguous( 1048576, MPI_DOUBLE, &myType );
>
>   int size;
>   MPI_Type_size( myType, &size );
> }
>
> Should MPI_Type_size return an error, due to overflow?  Does size  
> get set to MPI_UNDEFINED and the call succeeds?
>
> Similar issues exist for MPI_Pack with the outsize and position  
> parameters, MPI_Unpack with the insize and position parameters, and  
> MPI_Pack_size with the size parameter.
>
> Lastly, it is my belief that these parameters should really be of  
> type MPI_Aint, but changing this would break backward  
> compatibility.  They cannot be of type MPI_Count, since overflow can  
> occur if MPI_Count is defined as a C int.  How should the standard  
> handle this?
>
> Thoughts?
> -Fab
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign