After more than 20 years, how about making use of the "future extensibility" for the next standard to introduce more datarep arguments (like e.g. "native”)?

It could also be useful to define an “external64” data representation, to support LP64 systems better. Why is MPI_AINT 8 bytes in “external32”? I suppose that it was designed to support the IL32P64 (LLP64) data model, used in Windows. Unrelated, it may also be useful to define an MPI_SIZE_T datatype that can be used with size_t variables. Though I guess MPI_Aint and MPI_AINT can be used for that purpose as well.

I also wonder how to determine the exact size of a pack buffer. " A call to MPI_PACK_SIZE(incount, datatype, comm, size) returns in size an upper bound on the increment in position that is effected by a call to MPI_PACK(inbuf, incount, datatype, outbuf, outcount, position, comm).[...]

Rationale. The call returns an upper bound, rather than an exact bound, since the exact amount of space needed to pack the message may depend on the context (e.g., first message packed in a packing unit may take more space). (End of rationale.) "(MPI3.1, p. 135) There seems not to exist e.g. a routine to add up the sizes (INOUT size instead of position) analogous to the Pack procedure. Is there a function to determine the extra size for the first message (see Rationale). How should the exact buffer size (and not only an upper bound) be determinated before packing?

For the canonical MPI_PACK/MPI_UNPACK, there’s MPI_PACK_EXTERNAL_SIZE, which returns the exact size of the pack buffer. For the non-canonical MPI_PACK/MPI_UNPACK, you can only get an upper bound on the pack size, as the function doesn’t know if it’s the first message in a series of pack/unpack calls or not. MPI_PACK may, depending on the implementation, only need to store the header for the first message, while the others can be stored directly; however, MPI_PACK_SIZE can only assume that it’s the first message and thus would need space for the header as well. Omri Mor