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

Erez Haba erezh at [hidden]
Mon Aug 3 12:36:42 CDT 2009



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



More information about the Mpi-22 mailing list