My post was not a direct reaction to Darius' post; it was more in reaction to the general sense of "we need to pass this" that I've been (perhaps incorrectly) reading into some of the replies. Brian raised several good points in his mail about both procedural and technical issues that I agree need to be addressed before this issue can be passed into law. I see no reason to rush this into 2.2. On Mar 18, 2009, at 11:16 PM, Darius Buntinas wrote:

Sorry Jeff, I didn't think I was rushing anything. I'm not saying we shouldn't put it off till 3.0, but I was challenging the lack of const qualifiers on low-level interfaces as a reason to do so.

For the record, I do think that the fact that it would require significant changes in the Open MPI implementation is a legitimate reason to consider postponing this to 3.0. But we shouldn't wait till POSIX changes writev to use const qualifiers.

I wasn't at the last forum meeting, so maybe I missed discussion on this. So if I'm missing some context, I apologize. I'm not trying to rush this into 2.2, but I guess I'm not in a rush to push it off to 3.0 either.

-d

On 03/18/2009 08:24 PM, Jeff Squyres wrote:

...

Can someone explain what the rush is to do this for 2.2?

Is there a problem with putting this issue off until 3.0?

On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote:

...

I just want to point out that casting away the const for low-level interfaces is really a non issue. Putting a const on the send

buffer

...

parameter in an MPI function prototype indicates a contract with the user that the MPI implementation will not change the contents of the buffer referenced from that function. As long as the MPI implementor knows that a routine called by the library will not modify the buffer it's OK to cast away the const. E.g., the POSIX standard tells you that writev must not change the contents of the buffer, so casting away const is fine.

Sure, that means that the MPI implementor has to be more careful when casting away const to ensure that the function being called won't modify the buffer. But the whole point of the proposal is so that the _MPI_user_ doesn't need to do this and instead can count on the compiler to do the check.

-d _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

_______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

-- Jeff Squyres Cisco Systems