On Tue, 2017-09-05 at 17:21 +0000, Miller, Mark C. wrote: > Hmm. If I understand you, you have written code that you believe > produces an HDF5 file according to the 3.0 file version > specification, https://support.hdfgroup.org/HDF5/doc/H5.format.html > but nevertheless does NOT use the HDF5 library to do it. Furthermore, > where 'extended padding' is concerned, your implementation does > business differently than the HDF5 implementation. > > You can prove HDF5 tools will *read* the file ok. But, in a read- > modify-write scenario, the file is getting corrupted by HDF5 library > due to the difference in how the two implementations handle the > extended padding -- a feature that you explain is '...not defined at > all -- not even recommended'. > > Is that about right? > > If so, it does indeed sound like a potential issue in the file format > specification for HDF5. > > Your scenario sounds like a super useful test case...does a wholly > independent implementation produce a file the HDF5 library can > "handle"?
Over in Parallel-NetCDF land a few years back, we took, um, a "rather aggressive interpretation" of the NetCDF spec with respect to alignment and then opend a bug with Unidata when their tools did not follow the rules as written. As Mark observes, it was a productive exercise in keeping both implementations honest. ==rob _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
