There is no test suite requirement, only the availability of an implementation that can be examined. Rich ----- Original Message ----- From: mpi-22-bounces_at_[hidden] <mpi-22-bounces_at_[hidden]> To: MPI 2.2 <mpi-22_at_[hidden]> Sent: Fri Mar 20 16:26:11 2009 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to theCbindings-implementation Is a test suite is part of the requirement to accept this ticket? It if so, we will work it through and make one available. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 20, 2009 12:42 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation On Mar 19, 2009, at 9:20 PM, Pavan Balaji wrote:

...

- testing that const is in the right places in the interface is *exactly* the right kinds of tests to write.

Maybe I'm missing something here, but can you give some examples of tests that would fail with this change that a new and strict compiler will not be able to catch? Obviously I'm referring to cases which would work correctly if this ticket wasn't accepted, but will not work if it were.

Clearly, an implementor who passed a const variable through a non- const interface would get either a compiler warning or error. If the implementor disregards those messages, well, then I guess the battle is lost. ;-) 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.

Unless there are such examples, all this ticket requires is letting the compiler find the problems for you. In fact, some tickets in 2.1 required more QA, as a compiler was useless in catching any real problems with them and new tests had to be written (e.g., the change with respect to 0-dim cartesian topologies, or any other trivial change).

Sure, I wrote a few tests for this case for Open MPI. We try to write tests for most new major MPI functionality. But the 0-dim cartesian topologies creates a few tests, not 90+ tests.

So, what's the motivation to move this to 3.0?

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. -- Jeff Squyres Cisco Systems _______________________________________________ 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