[Mpi-forum] Review/Reading versions of #204 and #266

[Fab Tillier]

Martin Schulz wrote on Fri, 9 Sep 2011 at 09:58:46

> Hi Fab,
> 
> On Sep 9, 2011, at 9:42 AM, Fab Tillier wrote:
> 
>> Hi Martin,
>> 
>> As I won't be at the Greece meeting, I thought I would give you
>> feedback now.
>> 
>> I see that the string length handling is consistent with the silly precedent
>> set with functions like MPI_COMM_GET_NAME, where the buffer length on
>> input is assumed.  This is just bad software design, and I feel very
>> strongly that we should from this pattern and have the string length
>> specified on input by making the parameter INOUT just like you did for
>> the MPI_T interfaces.
> 
> Thanks for the feedback - I fully agree with you that the new type
> of string returns that we have adopted in MPI_T is much cleaner
> and I do prefer it as well.
> 
> However, this ticket was only intended as a minor addition since
> there was a common need and the forum liked the idea when I
> presented it last time. Changing the interface would mean larger
> changes by moving the interface descriptions up from MPI_T
> into the general document (since this shouldn't be twice in the
> document)and making it clear where it applies and where not
> (Which of the existing routines would we change, which not?
> Would we add double interfaces for existing routines?).

I've been thinking for a while now about how to handle the string lengths for the existing functions.  Changing the resultlen parameter to INOUT causes all sorts of pain from a backward compatibility perspective, so there really is no alternative than to have a new function.

This of course opens up the whole "suffix" discussion again, and I'd propose _s, just because that's the suffix Microsoft uses for the more secure versions of the C library functions like strcpy.  For example, strcpy_s takes an extra parameter specifying the destination string length.

> I would be happy to propose this as a separate ticket, but I would
> like to hear from the rest of the forum first on how they feel about
> this and what they think is the best way to do this. I am hesitant
> to make such a larger proposal without knowing in which
> direction this should go.

I would personally prefer to see the paragraph from the MPI_T chapter moved up.  Are you up for working on a ticket together?  We can move forward with the existing ticket, though it would likely change to follow whatever our follow up ticket would propose.

Does that seem reasonable?

-Fab

> 
> Martin
> 
> 
>> 
>> Cheers,
>> -Fab
>> 
>> Martin Schulz wrote on Fri, 9 Sep 2011 at 00:11:40
>> 
>>> Hi all,
>>> 
>>> I uploaded new versions of the proposals
>>> 
>>> #204: MPI_Get_library_version
>>>   (also contains two suggested ticket 0 changes for the
>>>    MPI Environmental Management chapter)
>>> #266: The MPI tool information interface
>>> 
>>> for comments and as the versions intended for the formal
>>> readings in Greece.
>>> 
>>> Please let me know if you have any questions or comments.
>>> 
>>> Thanks!
>>> 
>>> Martin
>>> 
>>> 
>>> PS: Rich - could you please add a reading for #204 to the
>>> MPI_T reading time slot? This should only take 10min and
>>> I was planning to do this either right before or after the
>>> MPI_T reading. Thanks!
>>> 
>>> 
>>> __________________________________________________________
>>> ______________ Martin Schulz, schulzm at llnl.gov,
>>> http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National
>>> Laboratory, Livermore, USA
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mpi-forum mailing list
>>> mpi-forum at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> 
> __________________________________________________________
> ______________ Martin Schulz, schulzm at llnl.gov,
> http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National
> Laboratory, Livermore, USA
> 
> 
>