[mpiwg-tools] proposed text

[Marc-Andre Hermanns]

Hi Kathryn,

if I understood right its a bit of both. We want to indicate that "our"
strings (or their handling) are different from the rest of the standard,
hence "MPI_T string" would be a good start. However, as I understand
Jeff, it implies that "this is how MPI_T handles strings everywhere" and
if we need some other handling of strings in MPI_T, we are then stuck
with a name that implies the full scope of MPI_T when it does not
provide it.

What about "quasi-identical" strings to explicitly name what we want to
express. Something along the lines of:

Quasi-identical strings in MPI_T are strings that behave as if they are
generated by a prefix-copy operation from a common source up to the
length provided locally to the call returning the string.

With something like this, we could then say, "foo" is a quasi-identical
strings as discussed in 14.3.3, wherever we need it, e.g., for name and
desc in the respective calls.

What do you think?

Cheers,
Marc-Andre

On 18.11.14 21:25, Kathryn Mohror wrote:
> I'm a bit lost on the intended meaning behind the name: <foo> strings.
> 
> Do you want <foo> strings to indicate all strings in the MPI tool
> information interface that are by our definition in 14.3.3 treated
> differently than in the rest of the standard? And then have a concept of
> identical <foo> strings and specify what is returned in the user's buffer
> for identical <foo> strings?
> 
> 
> Or is <foo> strings supposed to only indicate strings that if identical,
> have a particular defined behavior that determine what is returned into
> the user's buffer according to our string conventions in 14.3.3?
> 
> Thanks,
> Kathryn
> 
>>>> - so up in 14.3.3, have a definition for "<foo> strings" (someone come
>>>> up
>>>> with a better name than "<foo>"):
>>>
>>> MPI_T strings?
>>
>> Mmm.  That would imply that these are the *only* type of strings that are
>> used in MPI_T.  That may be true today, but I don't know if we want to be
>> locked in to that generalization for forever.
>>
>> How about "MPI_T universal strings"?
>>
>> -- 
>> 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
> 

-- 
Marc-Andre Hermanns
Jülich Aachen Research Alliance,
High Performance Computing (JARA-HPC)
German Research School for Simulation Sciences GmbH

Schinkelstrasse 2
52062 Aachen
Germany

Phone: +49 241 80 99753
Fax: +49 241 80 6 99753
www.grs-sim.de/parallel
email: m.a.hermanns at grs-sim.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4842 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20141118/9d7805d1/attachment-0001.bin>