From the "now that we're actually trying to implement this" category:
It turns out that MPI_TYPE_GET_ENVELOPE() is defined rather awkwardly because
it does not return the 'count' argument that was used when the supplied
datatype was created. This is not a fatal flaw, because the count can still be
derived from the other fields, but it is awkward because it depends on the
combiner. So I would argue that we really should add a 'count' return value for
this function.
Well, it used to return the count argument...
Observe that if we have count, we don't even need num_addresses, num_integers
or num_datatypes, since they can be derived easily from the count and combiner.
Count was deleted and those were added in a mad rush during one meeting
to fix some problems -- type-get-contents didn't handle some of the new
constructors (e.g., type-darray). I believe that argument for changing
type-get-envelope was that it might be necessary and that even if it
wasn't, it was 'more general'...
[And at the time type-darray took arrays of two sizes -- ndims and pdims.]
So, my minimal-change proposal is to add 'count' as an OUT argument. And my
maximal-elegance proposal is the above plus deleting the other three num_XXX
args.
I prefer the maximal-elegance proposal. With it, the type-get-envelope
binding would go back to what it was in the February 26th draft (except
for the updated list of combiners).
I view this almost as a bindings issue, since we are providing exactly the same
information as we were before. It's just in a more convenient form, and has
better symmetry with the type constructors. It also makes for a cleaner
separation between MPI_TYPE_GET_ENVELOPE() and MPI_TYPE_GET_CONTENTS().
I'm in favor of it, but worry somewhat about the slippery slope...
Comments? I know it's awfully late, but this would be a very localized change
to the document - certainly less sweeping than some of the other errors which
have been caught this week...
--
Eric Salo Silicon Graphics salo@sgi.com
David
-- david.taylor@East.Sun.COM