H5diff returns non-zero error code for 0 differerences found

HDF5 Library
1

I am using h5diff in 1.10.4 to ensure some endianess funnies I need to deal with in ZFP filter are being handled correctly. Part of that test invovles h5diff’ing ZFP compressed datasets from big endian and small endian machines. I am getting an exit code of 2 when there are zero diffs. This is problematic because I want to test h5diff error code to know if there are diffs. Am I using return code from h5diff incorrect? Has this behavior been changed?

env LD_LIBRARY_PATH=/Users/miller86/silo/hdf5-1.10.4/build_serial/my_install/lib:  HDF5_PLUGIN_PATH=../src/plugin /Users/miller86/silo/hdf5-1.10.4/build_serial/my_install/bin/h5diff -v -d 0.00001 test_zfp_le.h5 test_zfp_be.h5 compressed compressed
dataset: </compressed> and </compressed>
Warning: different storage datatype
</compressed> has file datatype H5T_IEEE_F64LE
</compressed> has file datatype H5T_IEEE_F64BE
0 differences found
[scratlantis:zfp_filter/H5Z-ZFP/test] miller86% echo $?
2

I should mention, unix diff tools return 0 on no diffs and non-zero (e.g. 1) on diffs and 2 I think if some kind of error occurs. I think h5diff should behave similarly.

2

Hi Mark,

h5diff is saying that the data is the same, but the files are not the same, because the datasets have different datatypes. The 2 is more of a warning in this case.

-Barbara

3

Hi Barbara,

Hmm. Is this behavior consistent across HDF5 versions? I don’t think it is because I have testing logic that was testing return code for this same use case in the past and it was yielding a zero in the past. Now, its not. I am pretty sure this is changed behavior.

Next, I don’t think the combination of 2 return code and the message 0 differences found is correct. At least, it isn’t correct w.r.t. to the way unix diff works which returns 0 when there are no diffs (actually I guess unix uses the term the files are identical which, in this case they are NOT but if one includes the timestamps HDF5 adds to object headers, can any two HDF5 files be considered identical without having to be copies of each other?).

I think 2 should be reserved for actual error cases, not cases where a diff can be performed. I think that behavior is more consistent with unix diff.

I think 1 should be returned when there are diffs according to the command-line options. Otherwise, if there are zero diffs, according to the command line options, 0 should be returned.

I think that is mostly consistent with how unix diff works.

So, I guess this is a long winded way of saying, I think current behavior represents a bug.

4

Hi Mark,

Thank you for the additional comments. I entered bug HDFFV-10699 for the issue.

We should determine what the correct return codes should be, correct any issues, and make sure that the behavior does not change from release to release.

Thanks!
-Barbara