Added another argument, expected node level, to H5B__iterate_helper to pass down
to H5B__cache_deserialize for checking the decoded node level. When this expected
level is not known, the new macro H5_UNKNOWN_NODELEVEL (-1) will be used for not
checking the level.
Fixes GH-4432
The name check in the FUNC_ENTER checks for private FUNC_ENTER macros
(which have NOAPI in the name) only checked for not having the
public form (H5Xfoo), so they could be inappropriately applied to
package-level functions (H5X__foo).
This PR fixes the bug and updates the inappropriate macros.
gcc 14 identifies likely places where the sizeof() call is used
for the first parameter to calloc(). This PR fixes the remaining
places in the library where this occurs and reworks a few other
allocations to be more uniform.
* Cast away a signed/unsigned issue in H5HFhuge.c
* Use our platform-independent POSIX types in external_common.c
and h5test.c
* Replace a memset() call with a (const) array initializer in h5test.c
* Fix an unused done: target in h5diff
The version number in the Autotools is scraped from README.md in configure.ac, which makes README.md count as 'code', which is a problem since changes to markdown files are ignored in CI.
This change scrapes the version number from H5public.h instead
of README.md.
* Split CMake HDFCompileFlags into specific compiler files
* Separate out CXX Flags
* Add Fortran compiler specific files
* Merge in #4816 changes and close#4816
* fix hanging endif
---------
Co-authored-by: Larry Knox <lrknox@hdfgroup.org>
Since each API context is local to a thread, use the stack to
store the context instead of allocating & releasing it each time.
This improves performance (slightly), reduces alloc/free calls,
and eliminates the H5FL package from the push & pop operations,
which helps simplify threadsafe operation.
One effect of this change is that the H5VLstart_lib_state /
H5VLfinish_lib_state API routines for pass through connector
authors now require a parameter that can be used to store
the library's context. It was probably a mistake to assume
that these two routines would not do this previously, so this
is essentially a bug fix for them.
Some other minor things:
* Added API context push+pop operations to cache tests
(I'm not actually certain why this was working before) and
a few other places
* Cleaned up a bunch of warnings in test code (calloc args, mainly)
* Made header file inclusions more standard in some source files
- Reverts PR#1024, which (unnecessarily) switched from deferred
package initialization to centralized initialization of all packages
and introduced H5FDperform_init() to wrap an internal routine
to initialize VFD plugins.
- Went back to deferred package initialization (primarily), to
eliminate unnecessary resource use. (Performance has been
verified to be the same either way)
- Switched VFD plugins to use “#define (H5OPEN, )” pattern,
with registration of internal VFD plugins at library initialization
time. Eliminates calling API routine (H5FDperform_init) from
within the library, which was deadlocking threadsafe concurrency.
And also eliminates exposing internal library routines in a public
header file.
- Removed copy-and-paste replicas of the H5OPEN macro and put
a (better) single definition in H5public.h
- Separated API and internal routine calls in stdio and multi VFD
plugins into separate source files, so that the library doesn’t
invoke API routines internally (also a deadlock problem for
threadsafe concurrency). Also needed a “private” header for these
plugins.
- Separated registering/unregistering a VFD plugin from initializing
/finalizing the plugin, instead of blurring those ideas together.
Defers the VFD plugin init to when it’s actually used, which reduces
resource usage, especially for the MPI-based plugins like the subfiling,
etc.
- Refactored the copy-and-pasted check for locking into a central
location in the H5FD.c code.
- Fixed a bunch of compiler warnings, especially ones that trigger CI
failures with -Werror
A recent bugfix to the library changed the return value of an API call
and a Julia CI action expects the incorrect result. This patch
papers over this until the upstream Julia wrapper CI can be fixed.
Also cleans up the links test, which had a ton of copy-and-pasted incorrect negative error checks (Calling TEST_ERROR within H5E_BEGIN_TRY / H5E_END_TRY pairs will goto out of the pair, leaving errors suppressed).
PR #4968 fixes a bug that causes the Julia CI to fail due to buggy
HDF5 behavior. The Julia CI will need to be updated to properly test
the fixed feature.
This was an unsupported build script to make building the library
with CMake look like building it with the Autotools. It hasn't been
maintained in a long time and we've had it marked as deprecated for
years.
These files are infrequently updated and generating them adds an
annoying dependency on Perl. We're checking them in and will
probably add a GitHub action to check if anything is stale
when creating a PR.
Adds:
* H5Edefin.h
* H5Einit.h
* H5Emajdef.h
* H5Emindef.h
* H5Epubgen.h
* H5Eterm.h
* H5overflow.h
* H5version.h
Solaris Studio hasn't been updated in almost a decade and the last
version (12.4, circa 2015) doesn't seem to fully support C11.
This PR removes some work-arounds for things like __attribute__()
support.
The CMake compiler checks skip checking for things like __attribute__()
on Windows. Now that Visual Studio can use clang, we should be checking
for this, even on non-MinGW Windows.
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.
The high-level GIF tools, h52gif and gif2h5, have unfixed CVE issues
(with no proof-of-concept files). They are not critical tools, are not
well maintained, and are an odd fit for building with the library.
Because of this, they have been removed. We may move them to a separate
repository in the future.
Ignores some of the older Autotools platform files, since the Autotools
will be dropped in the next major release (and we don't have
compilers on which to test, anyway).
Also drops support for the old, non-compliant MSVC
preprocessor.
Previously was hardcoding `-lzlib-static` which will result in the wrong
linker flags when built with system zlib. It looks like there was logic
to figure out the library name but the resulting `libname` was never used.