On 6 May 2014 00:05, Андрей Парамонов <[email protected]> wrote:
> Consider public function H5Gget_info, which takes 2 arguments:
>
> H5_DLL herr_t H5Gget_info(hid_t loc_id, H5G_info_t *ginfo);
>
> H5G_info_t is described as
>
> /* Information struct for group (for
> H5Gget_info/H5Gget_info_by_name/H5Gget_info_by_idx)
> */
> typedef struct H5G_info_t {
> H5G_storage_type_t storage_type; /* Type of storage for links in
> group */
> hsize_t nlinks; /* Number of links in group */
> int64_t max_corder; /* Current max. creation order
> value for group */
> hbool_t mounted; /* Whether group has a file
> mounted on it */
> } H5G_info_t;
>
> So, ginfo is a pointer to H5G_info_t structure somewhere in the heap or
> stack. Please note that H5G_info_t is not a primitive type. I'm not calling
> H5Gget_info from C program, so I need to know explicitly how exactly
> H5G_info_t members are laid out in memory, to access them. Might seem
> straightforward that the layout is (on my w32 machine):
>
> Offset Field
> 0 byte: storage_type
> 4 byte: nlinks
> 12 byte: max_corder
> 20 byte: mounted
>
> However, I discovered that the actual binary layout is:
>
> Offset Field
> 0 byte: storage_type
> 8 byte: nlinks
> 16 byte: max_corder
> 24 byte: mounted
>
> So, if I would try to access nlinks at offset 4, I would get incorrect
> value.
>
I don't think it's an alignment problem. I think this happens
because H5G_storage_type_t is an enum and the size of an enum in C is not
fixed (although is guaranteed to be big enough to contain an int).
See e.g.
http://stackoverflow.com/questions/366017/what-is-the-size-of-an-enum-in-c
my 2c,
Andrea
--
Andrea Bedini <[email protected]>
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://mail.lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
