Quincey Koziol wrote on Thu, 15 Jul 2010 at 00:50:14
Hi Fab, Sorry for the delay in replying...
On Jul 9, 2010, at 2:22 PM, Fab Tillier wrote:
Quincey Koziol wrote on Fri, 9 Jul 2010 at 12:05:52
I still think aliasing MPI_Size and MPI_Count will cause problems down the line, since the two concepts are different. I'd be much happier with separating them now rather than having to change things that are switched from int to MPI_Size now to MPI_Count later.
Having MPI_Size and MPI_Count different types causes MPI_Pack/MPI_Send and MPI_Recv/MPI_Unpack to have problems, since the count and sizes are passed between the two functions and should be interchangeable, though.
Well, there probably is something wrong with the definition of MPI_Pack and MPI_Unpack then. OK, I've gone off and re-read the definition of MPI_Pack in the standard and it looks OK to me. What is the problem with using MPI_Count for the 'incount' parameter and MPI_Size for the 'outsize' parameter?
When you go to MPI_Send a packed buffer, you would pass the 'outsize' as the count parameter, and MPI_PACKED as the datatype. If MPI_Size has a larger range than MPI_Count, you could run into problems. The converse is true of MPI_Recv and MPI_Unpack - if the MPI_Count type is larger than the MPI_Size type, you may not be able to unpack (you could receive more than what you can express in the call to MPI_Unpack.)
(I think I would suggest changing 'inposition' from a 'int *' to a 'void *' while we're mucking about in here, also)
The inposition is an offset from buf, it's an inout parameter thus being passed by reference so that MPI_Pack can update the position. -Fab