NATIVE_HBOOL storage

I've been working on integrating the output of a new instrument into our system, but when writing the streams to HDF, I was regularly getting out of bounds exceptions. And it took a good bit of searching to discover that the NATIVE_HBOOL types where I was storing several bool fields are actually stored as 4 byte uints (an hbool_t). So the structure I was sending to the Packet Table append() was sized badly since I was using 1 byte native bools.

Switching to uints seems to have solved the problem. But it seems startling that 4 bytes are needed to store, essentially a 1 bit value. Or am I missing something?

Scott

···

________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

Hi Scott,

···

On Feb 3, 2010, at 12:51 PM, Mitchell, Scott - IS wrote:

I’ve been working on integrating the output of a new instrument into our system, but when writing the streams to HDF, I was regularly getting out of bounds exceptions. And it took a good bit of searching to discover that the NATIVE_HBOOL types where I was storing several bool fields are actually stored as 4 byte uints (an hbool_t). So the structure I was sending to the Packet Table append() was sized badly since I was using 1 byte native bools.

Switching to uints seems to have solved the problem. But it seems startling that 4 bytes are needed to store, essentially a 1 bit value. Or am I missing something?

  Unfortunately, you are seeing the results of C99 overtaking the HDF5 datatypes. :-/ Our hbool_t was defined before there was a C99 standard and isn't the same as the C99 boolean type. We'd like to support the new C99 types in our next major release (1.10.0), but for now, I would avoid storing the HDF5 hbool_t type in files using it's "native" datatype.

  Quincey

Thanks Quincy,

Do you suggest I put my bool into a NATIVE_UCHAR or NATIVE_B8 or what?

Scott

···

From: hdf-forum-bounces@hdfgroup.org [mailto:hdf-forum-bounces@hdfgroup.org] On Behalf Of Quincey Koziol
Sent: Wednesday, February 03, 2010 2:49 PM
To: hdf-forum@hdfgroup.org
Subject: Re: [Hdf-forum] NATIVE_HBOOL storage

Hi Scott,

On Feb 3, 2010, at 12:51 PM, Mitchell, Scott - IS wrote:

I've been working on integrating the output of a new instrument into our system, but when writing the streams to HDF, I was regularly getting out of bounds exceptions. And it took a good bit of searching to discover that the NATIVE_HBOOL types where I was storing several bool fields are actually stored as 4 byte uints (an hbool_t). So the structure I was sending to the Packet Table append() was sized badly since I was using 1 byte native bools.

Switching to uints seems to have solved the problem. But it seems startling that 4 bytes are needed to store, essentially a 1 bit value. Or am I missing something?

          Unfortunately, you are seeing the results of C99 overtaking the HDF5 datatypes. :-/ Our hbool_t was defined before there was a C99 standard and isn't the same as the C99 boolean type. We'd like to support the new C99 types in our next major release (1.10.0), but for now, I would avoid storing the HDF5 hbool_t type in files using it's "native" datatype.

          Quincey

________________________________
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

Hi Scott,

Thanks Quincey,

Do you suggest I put my bool into a NATIVE_UCHAR or NATIVE_B8 or what?

  I would try to [portably] match it to the platform/compiler's choice for native bools. Something like this pseudo-code:

  switch(sizeof(bool)) {
  case 1:
    bool_type_id = H5T_NATIVE_UCHAR;
    break;

  case 2:
    bool_type_id = H5T_NATIVE_UINT16;
    break;

  case 4:
    bool_type_id = H5T_NATIVE_UINT32;
    break;
  .
  .
  .
        }

  Quincey

···

On Feb 3, 2010, at 2:13 PM, Mitchell, Scott - IS wrote:

Scott

From: hdf-forum-bounces@hdfgroup.org [mailto:hdf-forum-bounces@hdfgroup.org] On Behalf Of Quincey Koziol
Sent: Wednesday, February 03, 2010 2:49 PM
To: hdf-forum@hdfgroup.org
Subject: Re: [Hdf-forum] NATIVE_HBOOL storage

Hi Scott,

On Feb 3, 2010, at 12:51 PM, Mitchell, Scott - IS wrote:

I’ve been working on integrating the output of a new instrument into our system, but when writing the streams to HDF, I was regularly getting out of bounds exceptions. And it took a good bit of searching to discover that the NATIVE_HBOOL types where I was storing several bool fields are actually stored as 4 byte uints (an hbool_t). So the structure I was sending to the Packet Table append() was sized badly since I was using 1 byte native bools.

Switching to uints seems to have solved the problem. But it seems startling that 4 bytes are needed to store, essentially a 1 bit value. Or am I missing something?

          Unfortunately, you are seeing the results of C99 overtaking the HDF5 datatypes. :-/ Our hbool_t was defined before there was a C99 standard and isn't the same as the C99 boolean type. We'd like to support the new C99 types in our next major release (1.10.0), but for now, I would avoid storing the HDF5 hbool_t type in files using it's "native" datatype.

          Quincey

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org