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

HDF5 Library Library Development
1

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

1.14:

grafik
grafik704×160 12.3 KB

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!

2

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!

2 Likes
3

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.