<html><body>
<p>I once proposed that the standard should have something that can be used for any integer that has a range implied by the address range. MPI_Aint is billed as an address but the problem goes beyond adresses.<br>
<br>
I thought something like MPI_Sint (Size int) would have been a good idea from day one. I have not thought through the implications of adding MPI_Sint now but it would be as good as MPI_Count for that role and perhaps be applicable to some other cases too.<br>
<br>
This is just a thought. I do not have time at this point to really dig into what it would mean for the MPI 3 document<br>
<br>
Dick <br>
<br>
Dick Treumann - MPI Team <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-forum-bounces@lists.mpi-forum.org wrote on 06/19/2010 10:47:53 AM:<br>
<br>
> [image removed] </tt><br>
<tt>> <br>
> Re: [Mpi-forum] MPI_Type_size question</tt><br>
<tt>> <br>
> William Gropp </tt><br>
<tt>> <br>
> to:</tt><br>
<tt>> <br>
> Main MPI Forum mailing list</tt><br>
<tt>> <br>
> 06/19/2010 10:51 AM</tt><br>
<tt>> <br>
> Sent by:</tt><br>
<tt>> <br>
> mpi-forum-bounces@lists.mpi-forum.org</tt><br>
<tt>> <br>
> Please respond to Main MPI Forum mailing list</tt><br>
<tt>> <br>
> The standard doesn't say, but to me, the correct answer would be to <br>
> return an error with class MPI_ERR_OTHER. This follows the approach <br>
> of providing reliable failure when there is an error, with the user <br>
> able to set ERRORS_RETURN and check for the error. Returning <br>
> MPI_UNDEFINED allows the casual user to ignore the error, which is not <br>
> the MPI approach to errors.<br>
> <br>
> As to how to fix this, if we insist on backward compatibility, then we <br>
> need new routines, or we need another new type so that we can do the <br>
> same MPI_Count trick (which doesn't fix the problem but lets <br>
> implementations choose between backward compatibility and forward <br>
> compatibility).<br>
> <br>
> Bill<br>
> <br>
> On Jun 18, 2010, at 11:55 AM, Fab Tillier wrote:<br>
> <br>
> > Hi Folks,<br>
> ><br>
> > Looking at putting together the MPI_Count ticket, I ran across the <br>
> > following issue and was hoping to get some guidance. Take the <br>
> > following code, using the current int counts, and assume sizeof(int) <br>
> > == 4, sizeof(MPI_DOUBLE) == 8:<br>
> ><br>
> > {<br>
> > MPI_Datatype myType;<br>
> > MPI_Type_contiguous( 1048576, MPI_DOUBLE, &myType );<br>
> ><br>
> > int size;<br>
> > MPI_Type_size( myType, &size );<br>
> > }<br>
> ><br>
> > Should MPI_Type_size return an error, due to overflow? Does size <br>
> > get set to MPI_UNDEFINED and the call succeeds?<br>
> ><br>
> > Similar issues exist for MPI_Pack with the outsize and position <br>
> > parameters, MPI_Unpack with the insize and position parameters, and <br>
> > MPI_Pack_size with the size parameter.<br>
> ><br>
> > Lastly, it is my belief that these parameters should really be of <br>
> > type MPI_Aint, but changing this would break backward <br>
> > compatibility. They cannot be of type MPI_Count, since overflow can <br>
> > occur if MPI_Count is defined as a C int. How should the standard <br>
> > handle this?<br>
> ><br>
> > Thoughts?<br>
> > -Fab<br>
> ><br>
> > _______________________________________________<br>
> > mpi-forum mailing list<br>
> > mpi-forum@lists.mpi-forum.org<br>
> > <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
> <br>
> William Gropp<br>
> Deputy Director for Research<br>
> Institute for Advanced Computing Applications and Technologies<br>
> Paul and Cynthia Saylor Professor of Computer Science<br>
> University of Illinois Urbana-Champaign<br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> mpi-forum@lists.mpi-forum.org<br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
</tt></body></html>