Re: new filter proposal

John May (johnmay@llnl.gov)
Wed, 16 Apr 1997 18:05:51 -0700

Bill Nitzberg writes:
> 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.

I just wanted to verify that that's the behavior we're specifying
(implicitly, anyway). Given the earlier discussion about tiling
rules, the user will have to bound any external holes using a
call to MPI_Type_resize. I suppose the rule will be:

IF
(1) the type is a basic type or was created by MPI_Type_vector,
MPI_Type_indexed, or MPI_Type_contiguous
AND
(2) the upper and lower bounds are set at a offsets equal to an
integral multiple of the size of the base type

THEN
Any internal or external holes in the type will be expanded or
contracted in proportion to the change in size of the base type.

I think this is intuitively the right thing. Do others agree?

John