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
I'm labeling this as a bug even though technically it doesn't break anything for the codes/machines we use.
It would be better for hdf5 utils to always set the datatype for the memspace (during read/write calls) to the native type for the machine. This way we will always be able to read/write from/to both little- and big- endian files regardless of the sex of the machine. As it stands, io ops are only possible if the endianness of the file is the same as the machine itself.
Because hdf5 utils handles io in a type-agnostic way, implementing this requires being able to resolve the h5t native type for any specific user-chosen variable format.
The text was updated successfully, but these errors were encountered:
I'm labeling this as a bug even though technically it doesn't break anything for the codes/machines we use.
It would be better for hdf5 utils to always set the datatype for the memspace (during read/write calls) to the native type for the machine. This way we will always be able to read/write from/to both little- and big- endian files regardless of the sex of the machine. As it stands, io ops are only possible if the endianness of the file is the same as the machine itself.
Because hdf5 utils handles io in a type-agnostic way, implementing this requires being able to resolve the h5t native type for any specific user-chosen variable format.
The text was updated successfully, but these errors were encountered: