[mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?

[Jeff Squyres (jsquyres)]

How does it change semantics?

On Aug 14, 2014, at 4:09 PM, Schulz, Martin <schulz6 at llnl.gov> wrote:

> I would tend to agree with Kathryn, that this is more than ticket 0, since it does change semantics. It seems to me, though, that this is a clear bug in the specification and hence errata.
> 
> Martin
> 
> ________________________________________
> From: mpiwg-tools [mpiwg-tools-bounces at lists.mpi-forum.org] on behalf of Jeff Squyres (jsquyres) [jsquyres at cisco.com]
> Sent: Thursday, August 14, 2014 12:07 PM
> To: MPI Tool WG
> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
> 
> Is
> 
> s/0/false/g
> s/1/true/g
> 
> (where relevant, of course)
> 
> in the Tools chapter more than a ticket-0 change?
> 
> 
> On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1 at llnl.gov> wrote:
> 
>> Hi Jeff,
>> 
>> I see your point too. How do you propose to fix it? Make it clearer why we don't follow the same convention? Or change it to follow the rest of the standard? (The latter doesn't seem like ticket 0 to me.)
>> 
>> 
>> 
>> -- Kathryn
>> 
>> Sent with Good (www.good.com)
>> 
>> 
>> -----Original Message-----
>> From: Jeff Squyres (jsquyres) [jsquyres at cisco.com]
>> Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time
>> To: MPI Tool WG
>> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
>> 
>> I think the parts about the C convention/ignoring Fortran is fine.
>> 
>> But I think Junchao is raising the small-but-valid point that elsewhere in the doc, we say true/false for such things, but here in the tools chapter, we're saying 1/0.  So I'd say that this is a valid "consistency" kind of issue.
>> 
>> I'd further opine that this is a ticket 0 kind of change, and the chapter author should just make the change.
>> 
>> 
>> 
>> On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:
>> 
>>> Hi Junchao,
>>> 
>>> Thanks as always for your sharp eyes. I think though in this case that
>>> Nathan is correct. Since we only define a C interface for MPI_T and try to
>>> ignore Fortran altogether, it is okay to use the C convention for true and
>>> false.
>>> 
>>> Kathryn
>>> _________________________________________________________________
>>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
>>> USA
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn at mac.com> wrote:
>>> 
>>>> 
>>>> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang at mcs.anl.gov> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> It is a minor issue. In the Standard, the description for
>>>> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int
>>>> *atomic)
>>>> says:
>>>> Upon return, the argument readonly is set to zero if the variable can
>>>> be written or reset by the user. It is set to
>>>> one if the variable can only be read.
>>>> (Same thing happens to continuous and atomic.)
>>>> 
>>>> 
>>>> The description mandates an implementation must return 1 as TRUE, which
>>>> does not follow C's convention. Other parts of MPI use true/false instead
>>>> of 1/0 in description.  Section 2.6.3 make it clear that true means
>>>> non-zero.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> How does that not follow C¹s convention? C mandates that the evaluation
>>>> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1.
>>>> Returning 0/1 here makes perfect sense.
>>>> 
>>>> 
>>>> Other parts of MPI probably use true/false because fortran logicals do
>>>> not use 0/1 for false/true.
>>>> 
>>>> 
>>>> -Nathan Hjelm
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> --
> 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


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/