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