Pre-release versions of both HDFView 3.0 and HDF5-1.10.3 are now available. We encourage users to try them and let us know if you encounter any issues or have any suggestions.
HDFView 3.0 Pre-release
The pre-release version of HDFView 3.0 is available from the HDFView home page:
It is built with the pre-release version of HDF5-1.10.3 and with HDF 4.2.14. A final release of HDFView 3.0 will be available once HDF5-1.10.3 has been released. Many fixes and improvements have been added since the beta was introduced.
HDFView 3.0 is a major release that includes the following new features and changes:
It supports 64-bit object identifiers, and uses the HDF-Java wrappers that were added to HDF5 and HDF4.
The GUI framework that HDFView uses was migrated from Swing to SWT, which provides a more native application look and feel and advanced support for tables.
The data views have been separated from the main HDFView window. The main HDFView window still displays open files and their structures on the left side of the window, and it now displays any metadata on the right side.
This release includes improved support for various datatypes (compound, array of compound, and opaque).
For a complete list of the new features and changes in this release, please see the Release Notes.
HDF5-1.10.3 Pre-release
The HDF5-1.10.3 pre-release source code is available from the HDF Support Portal:
Several bugs were fixed in parallel compression in which:
Partial parallel reads of filtered datasets were returning incorrect data.
Partial parallel writes of filtered datasets triggered an assertion failure in the file free space manager.
The H5D__mpio_array_gatherv() function allocated too much memory.
The following CVEs have been addressed in this release:
CVE-2018-11202: A NULL pointer dereference was discovered in H5S_hyper_make_spans in H5Shyper.c.
CVE-2018-11203: A division by zero was discovered in H5D__btree_decode_key in H5Dbtree.c.
CVE-2018-11204: A NULL pointer dereference was discovered in H5O__chunk_deserialize in H5Ocache.c.
CVE-2018-11206: An out of bounds read was discovered in H5O_fill_new_decode and H5O_fill_old_decode in H5Ofill.c.
CVE-2018-11207: A division by zero was discovered in H5D__chunk_init in H5Dchunk.c.
The H5DreadVL and H5AreadVL Java APIs were refactored to correct dataset and attribute reads.
New APIs were added for accessing chunks: H5Dread_chunk and H5Dwrite_chunk
New versions of the following HDF5 Object (H5O) APIs were added to include additional parameters: H5Oget_info, H5Oget_info_by_idx, H5Oget_info_by_name, H5Ovisit, and H5Ovisit_by_name.
Several C++ wrappers were added or modified to provide additional support.
Code changes were made to improve performance.
The gcc attribute (no_sanitize) was moved before the function name to eliminate build issues with gcc 8.
For a complete list of the new features and changes in this release, please see the Release Notes.
Just tried to update from HDF5 10.1 to HDF5 10.4 in my codebase, and apparently HDF5 release 10.3 did break library API compatibility. Specifically, functions H5Oget_info, H5Oget_info_by_idx, H5Oget_info_by_name, H5Ovisit, H5Ovisit_by_name are now available either with new definition (suffixed with 2) or with original definition (suffixed with 1), but never by original name (without suffix).
Older client code relying on original names will break, as confirmed by e.g. https://github.com/JuliaIO/HDF5.jl/issues/508. It is proposed to export the original symbols using original names (without suffix) so older client code can still access them from the newer HDF5 libraries.
Previously, HDF5 used to publish very detailed and comprehensive compatibility reports, like this: https://support.hdfgroup.org/HDF5/doc/ADGuide/Compatibility_Report/CR_1.10.1.html
However, lately this practice ceased, unfortunately. Is it possible that compatibility report robot is re-vived, to avoid the risk of breakage in the future?
I don’t know how that happened, but we did discuss internally that in 1.10 releases the original signature should default to version 1. Somehow the change did not make it into the release.
Just a follow-up regarding the H5Oget_info APIs and the suffix issue…
The new H5Oget_info* APIs were added in HDF5-1.10.3, but unfortunately HDF5-1.10.3 did not configure the default APIs properly, so with that release the defaults were the versions ending in 2. We realized the mistake and fixed the issue in HDF5-1.10.4. However, this change did not make it into the release notes. It is now documented on the Software Changes From Release to Release page, here:
Please note that I did check against 1.10.4, and original symbols (without suffix) are missing from version 1.10.4 library as well. I think that the safest/proper solution for 1.10.5 would now be to have both original names (without suffix) and 1.10.3 names (with suffix “1”) for the old functions. We shall respect both pre-1.10.3 and 1.10.3…1.10.4-aware clients. If deemed to choose, I’m pretty sure there are more of the former than the latter, so having non-suffixed names again in 1.10.5 feels more important.
With the new versions of the H5Oget_info APIs, the version without the suffix is a macro that points to either the API ending in 1 or 2.
We went back and looked at the tagged versions of HDF5-1.10.3 and HDF5-1.10.4 and we actually did correctly set the macro.
I can compile the attached h5ex_g_iterate.c example with 1.10.1, 1.10.3, and 1.10.4. This example calls H5Oget_info_by_name, one of the APIs that changed.
Unfortunately, a piece of software compiled against HDF5 1.10.2 knows nothing about macros introduced later, and simply fails to locate expected symbol H5Oget_info_by_name when running against HDF5 1.10.3+. The API compatibility verdict is correct: backward compatibility is broken
