All: I have been quiet on this debate but I am to the point that I feel a need to speak up. I think the "significant changes" reason is a canard (I think Brian and Jeff believe it but it is still a red herring for the most part). The changes to support it are not significant. You can implement it by casting it away early. That does NOT eliminate the benefit to the user. Moving any casting that occurs lower does not change the user benefit; it changes the implementer CONFIDENCE that they are in fact conformant. But, if you are conformant you can cast it away immediately without error. Simply put, I have seen no convincing argument that any implementation actually requires significant changes. If implementers want increased confidence, they can delay obtaining that until the time frame they would provide their mistaken level required for conformance for 3.0. Bronis On Wed, 18 Mar 2009, 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