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
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. 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-t... 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)
participants (1)
-
unknown@example.com