[Mpi-22] Ticket #46: Add const Keyword to theCbindings-implementation

[Graham, Richard L.]

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