[mpiwg-tools] ticket 405: MPI_CHAR as string
Kathryn Mohror
kathryn at llnl.gov
Sat Feb 15 19:46:29 CST 2014
Thanks again for the feedback. I have incorporated it and attached the latest version.
Kathryn
On Feb 15, 2014, at 4:47 AM, Marc-Andre Hermanns <m.a.hermanns at grs-sim.de> wrote:
> +1
>
> I under stand the null-terminating character as "the character doing the
> null termination". As only the null character can do that, the text is
> clearer now.
>
> Cheers,
> Marc-Andre
>
> On 15.02.14 13:42, Jeff Squyres (jsquyres) wrote:
>> Sorry -- nit-picking on my own text:
>>
>> -----
>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its null-terminating character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first null-terminating character.
>> -----
>>
>> In the 2nd and 3rd sentence, we refer to the "null-terminating character". Is that correct? Isn't it just a "null character"?
>>
>> We use "null-terminated character array" in the first sentence, and that seems fine. But "null-terminated character" means "a character terminated by a null", which doesn't seem to make sense.
>>
>> In 14.3.3 ("Convention for Returning Strings"), we refer to the "null terminator" and "terminating null character").
>>
>> I therefore think we should slightly change the last 2 sentences to:
>>
>> -----
>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC must be large enough to include any valid value, including its ***terminating null*** character. The contents of returned MPI_CHAR arrays are only defined from index 0 through the location of the first ***null*** character.
>> -----
>>
>>
>>
>>
>> On Feb 14, 2014, at 6:16 PM, "Mohror, Kathryn" <mohror1 at llnl.gov> wrote:
>>
>>> Thanks for the feedback. I have attached a new draft for this ticket and incorporated your changes. Please give me any additional comments by the start of business Monday.
>>>
>>> Kathryn
>>>
>>> On Feb 14, 2014, at 7:23 AM, Dave Goodell (dgoodell) <dgoodell at cisco.com> wrote:
>>>
>>>> +1 to almost everything that Jeff said. My only quibble would be to change the last sentence in his text from:
>>>>
>>>> The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.
>>>>
>>>> To:
>>>>
>>>> The contents of returned MPI_CHAR ***arrays*** are only defined from index 0 through the location of the first null-terminating character.
>>>>
>>>> -Dave
>>>>
>>>> On Feb 14, 2014, at 7:27 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com> wrote:
>>>>
>>>>> Here's the new text:
>>>>>
>>>>> -----
>>>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e. a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC will include the null-terminating character. The value returned in count must be large enough to contain any valid value for the given variable. Arrays of type MPI_CHAR are only valid to the first null character.
>>>>> -----
>>>>>
>>>>> There's a missing "," after "i.e." -- it should be "i.e.,"
>>>>>
>>>>> I'd make some other minor changes:
>>>>>
>>>>> The use of the datatype MPI_CHAR in the MPI tool information interface implies a null-terminated character array, i.e., a string in the C language. If a variable has type MPI_CHAR, the value of the count parameter returned by MPI_T_CVAR_HANDLE_ALLOC and MPI_T_PVAR_HANDLE_ALLOC ***must be large enough to include any valid value, including its null-terminating character.*** ***The contents of returned MPI_CHAR values are only defined from index 0 through the location of the first null-terminating character.***
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Feb 13, 2014, at 3:24 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Please have a look at this since we have to decide if it's ready for a reading, and submit it to the forum for review on Monday if we do.
>>>>>>
>>>>>> Kathryn
>>>>>>
>>>>>> On Feb 7, 2014, at 1:05 PM, "Mohror, Kathryn" <mohror1 at llnl.gov> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As we discussed in our call, I have drafted new text for ticket 405 which clarifies our intent for the MPI_CHAR datatype to represent strings in the tools interface. Please take a look at the red text for ticket 405 in the attached document and send your comments.
>>>>>>>
>>>>>>> Kathryn
>>>>>>>
>>>>>>>
>>>>>>> _________________________________________________________________
>>>>>>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>>>>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <tools-3.pdf>_______________________________________________
>>>>>>> mpiwg-tools mailing list
>>>>>>> mpiwg-tools at lists.mpi-forum.org
>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>>>>
>>>>>> _________________________________________________________________
>>>>>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>>>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mpiwg-tools mailing list
>>>>>> mpiwg-tools at lists.mpi-forum.org
>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>>>
>>>>>
>>>>> --
>>>>> Jeff Squyres
>>>>> jsquyres at cisco.com
>>>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>
>>>>> _______________________________________________
>>>>> mpiwg-tools mailing list
>>>>> mpiwg-tools at lists.mpi-forum.org
>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>>
>>>> _______________________________________________
>>>> mpiwg-tools mailing list
>>>> mpiwg-tools at lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>>
>>> _________________________________________________________________
>>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> <tools-3.pdf>_______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>
>>
>
> --
> Marc-Andre Hermanns
> German Research School for
> Simulation Sciences GmbH
> c/o Laboratory for Parallel Programming
> 52062 Aachen | Germany
>
> Tel +49 241 80 99753
> Fax +49 241 80 6 99753
> Web www.grs-sim.de
>
> Members: Forschungszentrum Jülich GmbH | RWTH Aachen University
> Registered in the commercial register of the local court of
> Düren (Amtsgericht Düren) under registration number HRB 5268
> Registered office: Jülich
> Executive board: Prof. Marek Behr, Ph.D | Prof. Dr. Sebastian M. Schmidt
>
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140215/d90102ba/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tools-3.pdf
Type: application/pdf
Size: 326041 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140215/d90102ba/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140215/d90102ba/attachment-0003.html>
More information about the mpiwg-tools
mailing list