HDFGroup / HDFGroup/hdf5

Decide appropriate C type for chunk sizes

Open
#2,131 2 comments 0 reactions 1 assignee Claimed by @vchoi-hdfgroup View on GitHub
Component - C Library
Dominant language
C
Stars
988
Forks
355
Avg merge
4d 2h
Merged PRs (30d)
12

Description

From this discussion on HDF Forum: https://forum.hdfgroup.org/t/type-confusion-for-chunk-sizes/10235

[kittisopikulm](https://forum.hdfgroup.org/u/kittisopikulm)
1
[15d](https://forum.hdfgroup.org/t/type-confusion-for-chunk-sizes/10235)
[@ajelenak](https://forum.hdfgroup.org/u/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”?](https://forum.hdfgroup.org/t/what-do-you-want-to-see-in-hdf5-2-0/10003/19?u=kittisopikulm) 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](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title12), [H5Dget_chunk_info_by_coord 1](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title13), and [H5Dget_chunk_storage_size](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title14) making this possible.

[H5Dwrite_chunk 1](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title33) 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](https://docs.hdfgroup.org/hdf5/develop/_h5_dpublic_8h.html#ae32cf7f4c043511474e3f53590fda9cd) in 1.13 uses uint32_t, which I understand to be the current internal storage type for HDF5 chunks. I created an [issue 1](https://github.com/HDFGroup/hdf5/issues/2056) and potential [fix](https://github.com/HDFGroup/hdf5/pull/2074) 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?

[gheber](https://forum.hdfgroup.org/u/gheber)
[The HDF Group Staff](https://forum.hdfgroup.org/groups/The_HDF_Group)
[1d](https://forum.hdfgroup.org/t/type-confusion-for-chunk-sizes/10235/2)
[H5Dwrite_chunk ](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title33)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 problem is that size means different things in different APIs. In the case of H5Dwrite, chunk size is specified in bytes (in storage). In other places, chunk size is represented as the number of elements with an implicit reference to datatype element “size.”

Should the chunk size be canonically hsize_t (unsigned 64-bit integer) in all places?

Yes, if the unit is a dataype element count. No, if the unit is storage (or memory) byte size.

G.

[kittisopikulm](https://forum.hdfgroup.org/u/kittisopikulm)
[1d](https://forum.hdfgroup.org/t/type-confusion-for-chunk-sizes/10235/3)
All the functions I cited above are discussing bytes.

[H5Dget_chunk_info 1](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title12)
hsize_t * size
[out] size Chunk size in bytes, 0 if chunk doesn’t exist
[H5Dget_chunk_info_by_coord 1](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title13)
hsize_t * size
[out] size Chunk size in bytes, 0 if chunk doesn’t exist
[H5Dget_chunk_storage_size](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title14)
hsize_t * chunk_bytes
[out] chunk_bytes The size in bytes for the chunk
[H5Dwrite_chunk](https://docs.hdfgroup.org/hdf5/v1_12/group___h5_d.html#title33)
size_t data_size,
[in] data_size Size of the actual data to be written in bytes
[H5D_chunk_iter_op_t](https://docs.hdfgroup.org/hdf5/develop/_h5_dpublic_8h.html#ae32cf7f4c043511474e3f53590fda9cd)
uint32_t size
[in] size Chunk size in bytes, 0 if the chunk does not exist
The first three are hsize_t. The fourth is size_t. The fifth is uint32_t.

[@derobins](https://forum.hdfgroup.org/u/derobins) [makes the point](https://github.com/HDFGroup/hdf5/issues/2056) that they should all be uint32_t since chunk sizes are currently limited to 32-bits within the library.

[gheber](https://forum.hdfgroup.org/u/gheber)
[The HDF Group Staff](https://forum.hdfgroup.org/groups/The_HDF_Group)
[1d](https://forum.hdfgroup.org/t/type-confusion-for-chunk-sizes/10235/4)
Yikes! :slightly_frowning_face:

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.