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

[Hubert Ritzdorf]

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
>




* 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20090323/79df7e8b/attachment.bin>