John May replied:
> I think this will work. One question, though. Suppose an
> etype has a hole and the file extent is larger than the
> native extent. (Assume the hole is bounded by lower bound
> or an upper bound so it gets replicated correctly.) Depending
> on the type constructor that created the etype, the user might
> expect the hole to expand along with the basic type. For
> example, if the user creates an etype consisting of a float
> and a hole using MPI_Type_vector, and then bounds it using
> MPI_Type_resize, it would be reasonable to expect the size
> of the hole to match the size of the float. On the other
> hand, if the user creates a similar etype using MPI_Type_struct
> and an explicit upper bound, it might not be reasonable to
> expect the hole to change size. Do we need to specify this
> behavior? I think the problem comes up whether or not
> dtype_file_extent_fn accepts derived datatypes. If we don't
> specify the behavior, then I think it has to be erroneous
> to attempt a conversion when the etype contains a hole.
I think I'm missing the problem.
If an etype contains a hole the size of a float (e.g., Type_vector
example), then the implementation must keep track of the fact that
the hole is float-sized. When the implementation goes to skip over
that space in the file, it will use dtype_file_extent_fn to find the
size of a float, and skip that amount.
In the Type_struct example, the user has created a "non-portable"
datatype, and gets what they deserve.
- bill