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 <[email protected]> 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" <[email protected]> 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) <[email protected]> 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) <[email protected]> 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 <[email protected]> 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" <[email protected]> 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, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

<tools-3.pdf>_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

_________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

_______________________________________________ mpiwg-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

_________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

<tools-3.pdf>_______________________________________________ mpiwg-tools mailing list [email protected] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

_________________________________________________________________ Kathryn Mohror, [email protected], http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA