You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, HSDS removes all bytes of padding from compound types. This can lead to a re-opened datatype having a different total size, and different arrangement in memory than the type that a user originally wrote.
In order for HSDS to preserve the offsets of fields within compound types, it will probably need to accept an optional "offset" field for each field in a compound type, return this information as part of datatype reads, and then the client will need to use those (optional) offsets to re-assemble the datatype.
The text was updated successfully, but these errors were encountered:
In numpy there's no way it seems to specify the exact offsets of the fields. There's an alignment option: https://numpy.org/doc/stable/reference/generated/numpy.dtype.html, that can be used to flip between packed and compiler specified alignment. That might be the best we can do for now (though there could be potential issues sharing data between machines with different architectures)
Another alternative would be for clients that care about padding (C specifically) to add some extra fixed char elements as needed to adjust the alignment.
Currently, HSDS removes all bytes of padding from compound types. This can lead to a re-opened datatype having a different total size, and different arrangement in memory than the type that a user originally wrote.
In order for HSDS to preserve the offsets of fields within compound types, it will probably need to accept an optional "offset" field for each field in a compound type, return this information as part of datatype reads, and then the client will need to use those (optional) offsets to re-assemble the datatype.
The text was updated successfully, but these errors were encountered: