<html><body>
<p>There has been a first vote on this issue. I was not present for the discussion so I would like to present my argument for a different outcome on the second vote. The first vote opted for the position that MPI_TYPE_GET_CONTENTS should return information on empty type constructor inputs, ones that had replication count or block lengths arguments of zero. I do not think that is the best answer.  Here is the issue as stated in the ticket:<br>
<br>
================================<br>
MPI-2.1 introduced an ambiguity in the interpretation of what MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 introduced that user-defined datatypes could be created with zero counts for datatypes. The ambiguity originates from two sections of text: 
<ul>
<ul type="disc">
<li>MPI-2.1: p78:18-20 
<ul>
<ul>Most datatype constructors have replication count or block length arguments. Allowed values are nonnegative integers. If the value is zero, no elements are generated in the type map and there is no effect on datatype bounds or extent. </ul>
</ul>

<li>MPI-2.1: p107:47-48 
<ul>
<ul>The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to the datatypes used in the original construction call. </ul>
</ul>
</ul>
</ul>
<br>
=================================<br>
The alternatives provided were:<br>
say: <br>
The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to<br>
the datatypes used in the original construction call, including any zero-count datatypes that were <br>
specified in the original datatype constructor. <br>
<br>
say:<br>
 The datatypes returned in array_of_datatypes are handles to datatype objects that are equivalent to<br>
the significant datatypes used in the original construction call. <br>
(datatypes with 0 count or 0 blocklength are not considered significant) <br>
=================================<br>
<br>
Here are my arguments for the second option:<br>
<br>
1) The phrasing now in MPI-2.1: p78:18-20 enumerates the relevant "contents" of a datatype object and says none of these contents are affected by a parameter that represents 0 bytes. If an input parameter does not affect the "contents" it does not seem consistent to require that MPI_TYPE_GET_CONTENTS report that input.  The function is not MPI_TYPE_ECHO_ORIGINAL_ARGUMENTS.<br>
<br>
2) The primary uses for MPI_TYPE_GET_ENVELOP and MPI_TYPE_GET_CONTENTS are to provide a way for tools and opaque libraries to learn the data layout of a datatype created elsewhere. Any input to a type constructor that did not affect type signature, offsets, bounds or extent is irrelevant to this purpose. If MPI_TYPE_GET_CONTENTS returns this irrelevant history then the user of MPI_TYPE_GET_CONTENTS must have special case code to filter out this chaff. <br>
<br>
Note: there was a suggestion in the ticket that the the "user" who created a datatype that includes 0 byte members ought to be willing to deal with them when he calls MPI_TYPE_GET_CONTENTS - the problem with this logic is that the user who created such a datatype is not the user who must filter the output of MPI_TYPE_GET_CONTENTS.  Any user of MPI_TYPE_GET_CONTENTS that does not control the entire application will need to filter the output in case someone he cannot control produces datatypes with empty members. If he does not filter out this chaff, he must test all his algorithms that use the results of MPI_TYPE_GET_CONTENTS to ensure they tolerate empty members.<br>
<br>
3) As long as MPI_TYPE_GET_ENVELOP only counts those components that became part of the contents under MPI-2.1: p78:18-20, the effect is transparent for datatypes that represent at least one byte.  A totally empty datatype will return 0 for the envelope size and that ends the matter.  There is no need to call MPI_TYPE_GET_CONTENTS. If MPI_TYPE_GET_ENVELOP counts empty members then the user of MPI_TYPE_GET_CONTENTS will not know a datatype represents 0 bytes unless he adds code to check each member size.<br>
<br>
see ticket: <a href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2</a><br>
<br>
Dick Treumann  -  MPI Team           <br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846         Fax (845) 433-8363<br>
</body></html>