@ajelenak recently brought up “removing the contiguous storage layout and only have chunked and compact” in What do you want to see in “HDF5 2.0”? making me think about how chunks are exposed in the public API versus their internal library use.
I realized that much of the public chunk API wisely exposes chunk sizes as
hsize_t, an unsigned 64-bit integer such as in H5Dget_chunk_info, H5Dget_chunk_info_by_coord, and H5Dget_chunk_storage_size making this possible.
size_t rather than
hsize_t. For the most part, I think this is similarly also a unsigned 64-bit integer. I suppose
hsize_t could differ.
Should the chunk size be canonically
hsize_t (unsigned 64-bit integer) in all places? Is there another reason that the size in
H5Dwrite_chunk may differ? Does a change from
hsize_t require a versioned function to avoid breaking backwards compatability?