[Mpi-22] Ticket #46: Add const Keywordto theC bindings-implementation

[Jeff Squyres]

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