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 [email protected] 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