I have a stupid question: (*) Is it not required to write tests for all these interfaces (and internal protocols) where the (const) send buffer is declared and allocated as const also in the test program, so that the compiler is able to put the send buffer in special memory regions ? All other tests seem to be only compile tests (and not run tests) whether the internal interfaces are correctly declared. I think that the compiler doesn't have any possibility for optimization within the MPI library (and generating runtime problems with the const interface) since send buffer regions could be used as not const at any other location. Hubert Jeff Squyres wrote:
On Mar 20, 2009, at 4:32 PM, Pavan Balaji wrote:
The testing that I'm talking about would be writing tests to ensure that const was put in the right place in all the interfaces -- being able to repeatably prove that (i.e., regression testing). Be creative -- perhaps you can use the MPI's mpi.h with a test code that implements MPI_Send with const in the wrong parameter location. It should fail to compile, right? Or perhaps it has const in the right parameter location but then doesn't cast it away and intentionally modifies it. That should also fail, right? Those are good QA tests.
Thanks. With these tests are you testing the MPI implementation or the test program itself? If the application (or test program) uses a const in the wrong place, the compiler will throw a warning/error. And if the user decides to ignore it, there's nothing the MPI implementation can do about it.
I was giving a hypothetical test, probably with a big bias of my own MPI implementation. In Open MPI, the same mpi.h is used internally as externally. So a valid test could be to compile an application (or even just an object file) that "implements" MPI_Send, correctly and/or incorrectly. Since the mpi.h header file is the same as the one that is used internally, you can know that if your test MPI_Send "implementation" is wrong and still compiles ok, then your mpi.h is wrong. If your test is wrong and it doesn't compile, that's good (although it obviously doesn't necessarily mean that the mpi.h is correct).
What's the *need* to make this 2.2? Why such a strong push to get this in 2.2? What's the rush? As Brian noted, any MPI implementation can have const in their C bindings today, regardless of what happens in 2.2.
Inertia :-). Since the proposal is already in 2.2, I think the onus is to show an argument to *move* it to 3.0, rather than to keep it in 2.2.
By this logic, non-blocking collectives should be in 2.2 as well -- they have plenty of inertia! :-)
I think the onus should be to be careful and to get it right. We do strive for consensus in the Forum whenever possible. The procedural questions are being addressed (thanks, Erez!), but at least two technical questions remain:
- I (and others) have given examples why I (we) think this fails the "trivial" 2.2 implementation criteria - I (and others) have cited the disparity of lack of "const" in the callback function typedefs
--Jeff Squyres Cisco Systems
_______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
*