[Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A

Erez Haba erezh at [hidden]
Mon Aug 3 14:19:15 CDT 2009



Thanks.

-----Original Message-----
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner
Sent: Monday, August 03, 2009 11:04 AM
To: MPI 2.2
Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A

Hi Erez,

I thought that the first colored sentence
   "Constants with the type const int may also be implemented as
    literal integer constants substituted by the preprocessor."
allows to implement
>        #define MPI_ERR_BUFFER 0

[erezh] correct; however '#define MPI_ERR_BUFFER (int)0' is also an integer substituted by the pre-processor. I don't think that this sentence makes it clear enough.

Your second topic:
I'm not a C const specialist. I filled only in what I got as
input from the Forum.
If something is really wrong, we should use the errata method
as soon as possible.

[erezh] I was saying that it is confusing; I was not saying that the way you use const is wrong.
>From my pov, it would be better to remove the 'consts' for C in this section. unlike C++ where it's actually of a const type variable; the C value can be a literal or a variable.

Best regards
Rolf

On Mon, 3 Aug 2009 17:36:42 +0000
  Erez Haba <erezh_at_[hidden]> wrote:
> This might be nitpicking but wouldn't that force implementation to
>typecast their definition of error codes? For example,
>
>        #define MPI_ERR_BUFFER 0
>
> Is not a correct definition with the proposed change, because it is
>not typed. Thus, it needs to change to
>
> #define MPI_ERR_BUFFER (int)0   // you don't really need to define
>it as (const int)0
>
> as a result the following statement
>
>        short x = MPI_ERR_BUFFER;
>
> which compiled correctly before, would break with this change.
>
>
> Second comment.
>
> Adding the 'const' modifier to all types is very confusing imho. I
>understand that it meant to make it clear that the values are
>constants and should not change, but still is very confusing.
>
>For example,
>
>        C Type: void * const
>        MPI_BOTTOM
>
> This means that the value of MPI_BOTTOM is constant and not the
>memory it points to. however at first look you might think that it's
>the later. (if it was, it would break any application that uses it
>because the API's do not take a pointer to const void)
>
> In any case implementers should define MPI_BOTTOM as
>
>        #define MPI_BOTTOM (void*)0
>
> Rather than
>
>        #define MPI_BOTTOM (void* const)0
>
> As the value is constant and you don't need to add the const
>modifier.
>
>
> Note that the 'constness' of these values is already stated in the
>title of the section '19.1.1 Defined Constants'
>
>
> Except for my comments above, the text formatting looks good to me.
>(I abstained at the meeting)
>
> Just my 2c,
> .Erez
>
>
> P.S.it looks odd that the int and void* types have const modifiers
>while mpi types do not; like MPI_Datatype. I think that this needs to
>be consistent.
>
> -----Original Message-----
>From: mpi-22-bounces_at_[hidden]
>[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf
>Rabenseifner
> Sent: Monday, August 03, 2009 8:50 AM
> To: MPI Forum
> Subject: [Mpi-22] Borderline ticket #107: Types of predefined
>constants in Appendix A
>
> Dear all,
>
> ticket 107 was the only passed ticket with more no + abstain + miss
> votes
> than yes votes.
>
> MPI-2.1 had only C++ type information in this Appendix.
> With this ticket, C and Fortran type information is added
> to achieve consistency between all language bindings.
>
> I've implemented it and
> https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-ticket107-more-readable.pdf
> gives you an impression of the final (uncolored) document.
> (The new advices in Section 6.7.2 are not yet implemented).
>
> I hope you can now live with the result.
>
> If you would voted now with yes (based on the pdf),
> but you haven't voted yes at the meeting,
> then a short reply would be fine.
>
> The same of course if you now disagree with your yes at the meeting.
>
> Best regards
> Rolf
>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>rabenseifner_at_[hidden]
> High Performance Computing Center (HLRS) . phone
>++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 /
>685-65832
> Head of Dpmt Parallel Computing . . .
>www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22



More information about the Mpi-22 mailing list