h5close_f reset its count of the objects created by h5open_f with
CALL h5fget_obj_count_f(INT(H5F_OBJ_ALL_F,HID_T), H5F_OBJ_ALL_F, &
H5OPEN_NUM_OBJ, error)
passing the H5F module variable H5OPEN_NUM_OBJ as the actual argument for
the INTENT(OUT) obj_count dummy, while h5fget_obj_count_f also reads
H5OPEN_NUM_OBJ by use association. F2018 15.5.2.13 prohibits referencing a
variable through use association once it has been redefined through a dummy
argument in the same call, so the result depended on how the compiler
implemented argument association. Where the actual argument was passed by
reference the subtraction collapsed to 0 - 0 and produced the intended zero;
where the compiler used copy-in/copy-out it evaluated 0 - H5OPEN_NUM_OBJ and
left the count negative.
A negative count then defeats the guard at the top of h5open_f, which returns
early when H5OPEN_NUM_OBJ is non-zero. h5open_f reported success without
calling h5init_types_c, leaving H5T_NATIVE_INTEGER and the other predefined
types holding identifiers that h5close_f had released.
h5close_f now assigns the count directly, which is what the comment there has
always described. h5fget_obj_count_f computes into a local variable so that no
caller can reintroduce the aliasing; note that this change alone would make
the old h5close_f call site produce the negative count on every compiler
rather than only on some, so the two belong together. H5OPEN_NUM_OBJ is also
given an initial value, since h5open_f tests it before anything assigns to it.
h5fget_obj_count_f subtracted every object created by h5open_f from a count of
a single object type, so with the interface open a query such as
CALL h5fget_obj_count_f(INT(H5F_OBJ_ALL_F,HID_T), H5F_OBJ_FILE_F, n, error)
returned a negative n and hdferr of 0. h5open_f now records what it leaves open
per object type, and a count is adjusted by the recorded value for the types
being counted, so the adjustment does not depend on which types the
initialization creates. The check for a negative count runs both on the value
returned by H5Fget_obj_count and after the adjustment.
h5fget_obj_ids_f applied no such adjustment, so it returned the identifiers
h5open_f opened alongside the application's own and disagreed with
h5fget_obj_count_f about the same query: with only a file and a group open,
H5F_OBJ_ALL_F counted 2 objects but listed 62. The C API reports 2 and 2. An
application walking the list found datatypes it never opened, and closing them
breaks the Fortran interface. h5fget_obj_ids_f now excludes those identifiers,
requesting enough from H5Fget_obj_ids that max_objs of the application's own
can still be returned when the two are interleaved.
The h5open/h5close test verified its object counts by calling
h5fget_obj_count_f after h5close_f, when h5open_f is the only call the Fortran
interface permits. Those checks move to after the interface is reopened, where
they additionally confirm that the predefined types are valid again, that the
preceding h5close_f released the previous h5open_f's types, and that
h5fget_obj_ids_f agrees with h5fget_obj_count_f.
The Fortran tests also aborted unrecoverable failures with STOP, which exits
with a success status whether the stop code is absent or is a string, so a run
that died part way through reported no failure to CTest. They now exit through
h5_exit_f(1). The STOPs that end a run normally, in fflush1 and in the async
test's skip path for a build without MPI_THREAD_MULTIPLE, are unchanged.
Fixes#6642Fixes#6648
Reported and diagnosed by Dom Heinzeller.
All #cmakedefine01 CMAKE_H5_* blocks used a five-line pattern:
#cmakedefine01 CMAKE_H5_HAVE_FOO
#if CMAKE_H5_HAVE_FOO == 0
#undef H5_HAVE_FOO
#else
#define H5_HAVE_FOO
#endif
This is exactly what #cmakedefine H5_HAVE_FOO does: it emits
#define H5_HAVE_FOO (no value) when the CMake variable is truthy and
/* #undef H5_HAVE_FOO */ when falsy. The CMAKE_H5_* intermediate
variables in fortran/src/CMakeLists.txt were only needed to feed these
blocks and are no longer required.
Replace all such blocks with #cmakedefine H5_HAVE_FOO, using the H5_*
variable directly. MPI_LOGICAL_KIND retains its value via
#cmakedefine H5_MPI_LOGICAL_KIND @H5_MPI_LOGICAL_KIND@.
This also fixes a real bug: H5_FORTRAN_C_BOOL_IS_UNIQUE was emitted as
#define H5_FORTRAN_C_BOOL_IS_UNIQUE 0 when C_BOOL and default LOGICAL
are the same kind (e.g. Apple PowerPC ABI). #ifdef only tests whether
a macro is defined, not its value, so the guard in H5_test_buildiface.F90
was always true and verify_c_bool was written into tf_gen.F90 regardless,
causing an "Ambiguous interfaces" build failure on that platform.
Refactor the cross-compilation infrastructure to rely on the standard
CMAKE_CROSSCOMPILING_EMULATOR variable instead of the custom
CROSSCOMPILING_PATH environment hack.
Key changes:
- Removed `ENVIRONMENT "${CROSSCOMPILING_PATH}"` from all test definitions.
- Updated custom commands (e.g., H5match_types, H5_gen) to invoke the
emulator explicitly when cross-compiling.
- Updated ConfigureChecks.cmake and HDF5UseFortran.cmake to enable
`try_run` checks when an emulator is defined.
- Added config/toolchain/mingw-w64-x86-64-wine.sh wrapper to automatically
locate MinGW runtime libraries (like libgfortran) for Wine execution.
- Cleaned up toolchain files to remove hardcoded emulator paths, deferring
configuration to the build environment.
* Add Fortran wrappers for H5Fstart_swmr_write, H5Dflush, and H5P{set,get}_append_flush
* corrected C doxygen docs for H5Pget_append_flush, clarified Fortran
Change default file format to 1.8 across various tests and examples, updating file creation and access logic accordingly.
Behavior:
Default file format version changed to 1.8 in H5Pfapl.c.
Updated file creation and access to use 1.8 format in h5ex_g_compact.c and test_file_image.c.
Set earliest file format in multiple test files including cache_tagging.c, dtypes.c, and links.c.
Tests:
Modified expected output in tools/test/misc/expected/*.ls files to reflect new file format locations.
Adjusted test logic in test_file_image.c and cache_tagging.c to accommodate format changes.
Misc:
Added comments and TODOs for future format testing in test_file_image.c.
Minor variable renaming for clarity in test_file_image.c.
Behavior:
Modify HDF5UseFortran.cmake to handle cross-compilation by providing default KINDs and sizes when CMAKE_CROSSCOMPILING is true.
Default values for INTEGER and REAL KINDs and their sizes are set when cross-compiling.
Error messages are adjusted to reflect cross-compilation scenarios.
Logic:
Conditional checks added for CMAKE_CROSSCOMPILING to determine if default values should be used.
Default values include INTEGER KINDs {1,2,4,8,16} and REAL KINDs {4,8,10,16}.
Default sizes for native kinds are set to 4 for INTEGER and REAL, and 8 for DOUBLE PRECISION when cross-compiling.
Misc:
Adjustments to verbose messages to indicate when defaults are used during cross-compilation.
Optimize VDS operations using R-tree spatial index, adding new API functions and tests for improved performance.
Behavior:
Introduces R-tree spatial index for optimizing VDS operations in H5Dvirtual.c.
Adds H5Pset_dset_use_spatial_tree() and H5Pget_dset_use_spatial_tree() to control R-tree usage.
Default behavior uses R-tree for VDS with more than 1000 mappings.
Implementation:
Adds H5RT.c, H5RTprivate.h, and H5RTpkg.h for R-tree implementation.
Updates H5Pdapl.c and H5Pdcpl.c to include R-tree properties.
Modifies H5Dvirtual.c to integrate R-tree in VDS I/O operations.
Testing:
Adds rtree.c for testing R-tree creation, search, and copy operations.
Tests R-tree integration with VDS in test/dsets.c.
Verifies R-tree behavior with different dataset access property list settings.
* Simplify H5api_adpt.h
This change also uses the shared markup (e.g., __declspec) in both
static and shared libraries as the shared markup is ignored when
building static libs.
* Renamed some API decorations
Some API decorations (used to hide __declspec on Windows, among other
things) have been renamed:
H5_DLLCPP(VAR) --> H5CPP_DLL(VAR)
H5_HLDLL(VAR) --> H5HL_DLL(VAR)
H5_HLCPPDLL(VAR) --> H5CPP_HL_DLL(VAR)
H5_FCDLL(VAR) --> H5FC_DLL(VAR)
H5_FCTESTDLL(VAR) --> H5FC_TEST_DLL(VAR)
HDF5_HL_F90CSTUBDLL(VAR) --> H5FC_HL_DLL(VAR)
The shared library decorations are also now used when building static
libraries (where they are meaningless and ignored).
This is where most people will expect to find license information. The
COPYING_LBNL_HDF5 file has also been renamed to LICENSE_LBNL_HDF5.
The licenses are unchanged.
Cleanup and prepare for thread-safety changes.
Big ideas:
* Wrap H5VL_class_t with H5VL_connector_t, so use of the class can be refcounted within the H5VL package, instead of relying on storing an ID within the H5VL_t struct and incrementing & decrementing the ID's refcount.
* Register H5VL_connector_t* for VOL connector IDs, instead of the H5VL_class_t*
* Stop other packages from rummaging around inside H5VL_connector_t and H5VL_object_t data structures, so that the H5VL package can change implementation details without coupled changes throughout the library
Small things:
* Simplified the coding for creating links
* Moved some routines into more logical locations
* Always use DECIMAL_DIG instead of LDBL_DIG. This was controlled by
an ifdef that is always true in C99 or greater
It's confusing to use float.h C constants as variable names in
configure.ac and the PAC_FC_LDBL_DIG macro.
* Directly compare MY_FLT128_DIG and MY_LDBL_DIG
* Make uniform across CMake and Autotools
* Don't export quadmath.h variables to H5pubconf.h
- Add Fortran H5R APIs:
h5rcreate_attr_f, h5rcreate_object_f, h5rcreate_region_f,
h5ropen_attr_f, h5ropen_object_f, h5ropen_region_f,
h5rget_file_name_f, h5rget_attr_name_f, h5rget_obj_name_f,
h5rcopy_f, h5requal_f, h5rdestroy_f, h5rget_type_f
- Fixed function H5Requal actually to compare the reference pointers
Fixed an issue with H5Requal always returning true because the
function was only comparing the ref2_ptr to itself.
* addressed issue wit promoted integers and reals
* fixed h5fcreate_f
* added option to use mpi_f08
* change the kind of logical in the parallel tests
* addressed missing return value from callback