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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
__________________________________________________________ ______________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA