@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.
H5Dwrite_chunk uses size_t rather than hsize_t. For the most part, I think this is similarly also a unsigned 64-bit integer. I suppose size_t and hsize_t could differ.
The recent H5Dchunk_iter in 1.13 uses uint32_t, which I understand to be the current internal storage type for HDF5 chunks. I created an issue and potential fix for this.
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 size_t to hsize_t require a versioned function to avoid breaking backwards compatability?
