# H5dump 1.14 gives error with fill value (1.12 is ok)

**URL:** <https://forum.hdfgroup.org/t/h5dump-1-14-gives-error-with-fill-value-1-12-is-ok/11385>\
**Category:** Library Development\
**Created:** [July 31, 2023, 1:45pm UTC](https://forum.hdfgroup.org/t/h5dump-1-14-gives-error-with-fill-value-1-12-is-ok/11385 "2023-07-31T13:45:03Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![apollo3zehn-h5](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/apollo3zehn-h5/32/1589_2.png) [@apollo3zehn-h5](https://forum.hdfgroup.org/u/apollo3zehn-h5)\
**Post date:** [July 31, 2023, 1:45pm UTC](https://forum.hdfgroup.org/t/h5dump-1-14-gives-error-with-fill-value-1-12-is-ok/11385/1 "2023-07-31T13:45:03Z")

</div>

I try to write a fill value message version 3 where the fill value is undefined. This works fine for h5dump 1.12 and lower (it can dump the file) but fails for version 1.14 with the error `have value and undefined value flags both set`.

The block of code where this error occurs has actually changed between both versions:

1.12:  
 ![grafik](https://dbkt.hdfgroup.org/original/2X/f/fe75226a22245a88c28e9126c6b4dbe5c1a0ba1d.png)

1.14:

 ![grafik](https://dbkt.hdfgroup.org/original/2X/9/9de4782e8b49a8f6e40132931a58dd72cbd34db3.png)

The 1.12 condition `!(flags & H5O_FILL_FLAG_HAVE_VALUE)` (which makes sense) has changed in 1.14 to `flags & (unsigned)~H5O_FILL_FLAG_HAVE_VALUE` which I do not understand.

More specifically, I do not understand why the constant `H5O_FILL_FLAG_HAVE_VALUE` is being inverted using the tilde operator (`~`). Without that operator, this line of code would simply check if bit 5 is set but with the inverting operation it checks if any bit is set and bit 5 is being ignored. This must always fail (i.e. H5GOTO\_ERROR is invoked) because bit 4 (`H5O_FILL_FLAG_UNDEFINED_VALUE`) is set and so the if condition is fulfilled.

I think the new code will always fail if the fill value is undefined. Or maybe I have some misunderstanding of the code, but my tests show that everything is fine with the 1.12 branch and it starts to fail with the 1.14 branch.

Thanks again!

---

<div class="post-metadata">

**Author:** ![jhenderson](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/j/73ab20/32.png) [@jhenderson](https://forum.hdfgroup.org/u/jhenderson)\
**Post date:** [July 31, 2023, 9:05pm UTC](https://forum.hdfgroup.org/t/h5dump-1-14-gives-error-with-fill-value-1-12-is-ok/11385/2 "2023-07-31T21:05:44Z")

</div>

Hi @apollo3zehn-h5,

I agree with your interpretation of the change in the code here. I believe that the condition was meant to simply be `if (flags & H5O_FILL_FLAG_HAVE_VALUE)` and that there was likely a copy-paste issue from the block above that reads:

```
if (flags & (unsigned)~H5O_FILL_FLAGS_ALL)
    HGOTO_ERROR(H5E_OHDR, H5E_CANTLOAD, NULL, "unknown flag for fill value message")

```

It looks like this was missed in testing due to not having thorough enough testing for undefined fill values where both the file and dataset in question need to be re-opened in order to trigger the library decoding the object header message for the fill value. Just closing and re-opening the dataset in question doesn’t appear to be enough to trigger the issue in tests likely due to some caching effects; I should have a PR out soon to fix this issue.

Thanks for the catch!

---

<div class="post-metadata">

**Author:** ![apollo3zehn-h5](https://forum.hdfgroup.org/user_avatar/forum.hdfgroup.org/apollo3zehn-h5/32/1589_2.png) [@apollo3zehn-h5](https://forum.hdfgroup.org/u/apollo3zehn-h5)\
**Post date:** [August 1, 2023, 7:59am UTC](https://forum.hdfgroup.org/t/h5dump-1-14-gives-error-with-fill-value-1-12-is-ok/11385/3 "2023-08-01T07:59:57Z")

</div>

Thanks for your quick reply, I will then default to write fill value messages with defined fill value where the fill value itself consists of zeros. I guess that is the default for the C library anyway.