HDF5 documents and links Introduction to HDF5 HDF5 User’s Guide | In the HDF5 Reference Manual H5DS H5IM H5LT H5PT H5TB Optimized H5 H5A H5D H5E H5F H5G H5I H5L H5O H5P H5PL H5R H5S H5T H5Z Tools Datatypes Fortran Compatibility Macros Collective Calls in Parallel

# API Compatibility Macros in HDF5

### Audience

The target audience for this document has existing applications that use the HDF5 Library, and is considering moving to HDF5 Release 1.10.x to take advantage of the latest library features and enhancements.

### Compatibility Issues

HDF5 Release 1.10.0 is a major update of the HDF5 Library. Certain compatibility issues must be considered when migrating applications from an earlier major release series, such as 1.8.x or 1.6.x, to a HDF5 1.10.x release.

This document, “API Compatibility Macros in HDF5,” describes the approach taken by The HDF Group in HDF5 Release 1.10.0 to help existing users of HDF5 address compatibility issues in the HDF5 API. A companion document, New Features in HDF5 Release 1.10.0, discusses features introduced in HDF5 Release 1.10.0 and the HDF5 API calls associated with those features.

### Summary and Motivation

In response to new and evolving requirements for the library and data format, several basic functions have changed since HDF5 was first released. To allow existing applications to continue to compile and run properly, all versions of these functions have been retained in the later releases of the HDF5 Library.

HDF5 Release 1.10.0 includes a number of new features that offer users of HDF5 substantial performance improvements and expanded capabilities. Some of these features can only be accessed via revised API calls. Given the scope of the changes, and recognizing the potentially time-consuming task of editing all the affected calls in user applications, The HDF Group has created a set of macros that can be used to flexibly and easily map existing API calls to either 1.6.x, 1.8.x, or 1.10.x functions. We refer to these as the API compatibility macros.

The HDF Group generally encourages users to update applications to work with the latest HDF5 Library release so that all new features and enhancements are available to them. At the same time, The HDF Group understands that, under some circumstances, updating applications may not be feasible or necessary. The API compatibility macros, described in this document, provide a bridge from old APIs to new and can be particularly helpful in situations such as these:

- Source code is not available - only binaries are available; updating the application is not feasible.
- Source code is available, but there are no resources to update it.
- Source code is available, as are resources to update it, but the old version works quite well so updates are not a priority. At the same time, it is desirable to take advantage of certain efficiencies in the newer HDF5 release that do not require code changes.
- Source code is available, as are resources to update it, but the applications are large or complex, and must continue to run while the code updates are carried out.

### Understanding and Using the Macros

As part of HDF5 Release 1.10.0, two functions that existed in previous versions of the library were updated with new calling parameters and given new names. The updated versions of the functions have a ‘2’ at the end of the original function name. The original versions of these functions were retained and renamed to have a ‘1’ at the end of the original function name. In one case, `H5Fget_info`, the change is in the struct employed by the function. In this case, the struct was versioned in exactly the same manner as the function. API compatibility macros, with the same names as the original function and struct names, were then created.

Note that twenty-three versioned functions and corresponding macros were introduced in HDF5 Release 1.8.0. These functions and macros were created in exactly the same manner discussed in the preceding paragraph.

Concretely, consider the function `H5Rdereference` in HDF5 releases prior to 1.10.0:

Original function name and signature, in releases prior to 1.10.0:
`hid_t H5Rdereference( hid_t `obj_id`, H5R_type_t `ref_type`, void *`ref` )`
Updated function and signature, introduced in release 1.10.0:
`hid_t H5Rdereference2( hid_t `obj_id`, hid_t `oapl_id`, H5R_type_t `ref_type`, void *`ref` )`
Original function and signature, renamed in release 1.10.0:
`hid_t H5Rdereference1( hid_t `obj_id`, H5R_type_t `ref_type`, void *`ref` )`
API compatibility macro, introduced in release 1.10.0:
`H5Rdereference`

The macro, `H5Rdereference`, will be mapped to either `H5Rdereference1` or `H5Rdereference2`. The mapping is determined by a combination of the configuration options use to build the HDF5 Library and compile-time options used to build the application. The calling parameters used with the `H5Rdereference` compatibility macro should match the number and type of the function the macros will be mapped to (`H5Rdereference1` or `H5Rdereference2`).

The function names ending in ‘1’ or ‘2’ are referred to as versioned names, and the corresponding functions are referred to as versioned functions. For new code development, The HDF Group recommends use of the compatibility macro mapped to the latest version of the function. The original versions of these functions, with names ending in ‘1’, should be considered deprecated and, in general, should not be used when developing new code.

Compatibility Macro Mapping Options

To determine the mapping for a given API compatibility macro in a given application, a combination of user-controlled selections, collectively referred to as the compatibility macro mapping options, is considered in the following sequence:

What compatibility macro configuration option was used to build the HDF5 Library? We refer to this selection as the library mapping. Was a compatibility macro global compile-time option specified when the application was built? We refer to this (optional) selection as the application mapping. If an application mapping exists, it overrides the library mapping. (See adjacent notes.) Were any compatibility macro function-level compile-time options specified when the application was built? We refer to these (optional) selections as function mappings. If function mappings exist, they override library and application mappings for the relevant API compatibility macros. (See adjacent notes.) |
Notes: An application mapping can map APIs to the same version or to a version older than the configured library mapping. When the application attempts to map APIs to a newer version of the API than the library was configured with, it will fail to “upgrade” the mapping (and may fail silently). When it is necessary to “upgrade” the macro mappings from those set in the library mapping, it must be done at the per-function level, using the function-level mappings. As long as one does not try to map a function to a version that was compiled out in the library mapping, individual functions can be upgraded or downgraded freely.

The tables that follow summarize the macro mapping behaviors, and the configuration and compile-time options that control the mappings. The macro `H5Rdereference` is used to demonstrate mapping behavior.

Regardless of the macro mapping options used, the 1.10.x functions will always be available by explicitly calling the versioned functions by their versioned names. For example, `H5Rdereference2`. Through the compatibility macro mapping options provided, it is possible to disallow calls to the deprecated 1.8.x functions, such as `H5Rdereference1`. This capability can be used to guarantee that only the most recent versions of the functions are being called.

Library Mapping Options

When the HDF5 Library is built, `configure` flags can be used to control the API compatibility macro mapping behavior exhibited by the library. This behavior can be overridden by application and function mappings. One configure flag excludes deprecated functions from the HDF5 Library, making them unavailable to applications linked with the library.

Table 1: Library Mapping Options
`configure` flag | Macros map to release (versioned function; `H5Rdereference` shown) | Deprecated functions available? (`H5Rdereference1`)
--- | --- | ---
`--with-default-api-version=v110` Default behavior if no flag is specified. | 1.10.x (`H5Rdereference2`) | yes
`--with-default-api-version=v18` | 1.8.x (`H5Rdereference1`) | yes
`--with-default-api-version=v16` | 1.6.x (`H5Rdereference1`) | yes
`--disable-deprecated-symbols` | 1.10.x (`H5Rdereference2`) | no

Refer to the file `libhdf5.settings` in the directory where the HDF5 Library is installed to determine the `configure` flags used to build the library. In particular, look for the two lines shown here:

`Default Version of Public Symbols: v110
With Deprecated Public Symbols: Yes`

Application Mapping Options

When an application using HDF5 APIs is built and linked with the HDF5 Library, compile-time options to `h5cc` can be used to control the API compatibility macro mapping behavior exhibited by the application. The application mapping overrides the behavior specified by the library mapping, and can be overridden on a function-by-function basis by the function mappings.

If the HDF5 Library was configured with the `--disable-deprecated-symbols` flag, then the deprecated functions will not be available, regardless of the application mapping options.

Table 2: Application Mapping Options
`h5cc` option | Macros map to release (versioned function; `H5Rdereference` shown) | Deprecated functions available? (`H5Rdereference1`)
--- | --- | ---
Default behavior if no option specified. | 1.10.x (`H5Rdereference2`) | yes* *if available in library
`-DH5_USE_18_API` | 1.8.x (`H5Rdereference1`) | yes* *if available in library
`-DH5_USE_16_API` | 1.6.x (`H5Rdereference1`) | yes* *if available in library
`-DH5_NO_DEPRECATED_SYMBOLS` | 1.10.x (`H5Rdereference2`) | no

Function Mapping Options

Function mappings are specified when the application is built. These mappings can be used to control the mapping of the API compatibility macros to underlying functions on a function-by-function basis. The function mappings override the library and application mappings discussed earlier.

If the HDF5 Library was configured with the `--disable-deprecated-symbols` flag, or `-DH5_NO_DEPRECATED_SYMBOLS` is used to compile the application, then the deprecated functions will not be available, regardless of the function mapping options.

For every function with multiple available versions, a compile-time version flag can be defined to selectively map the function macro to the desired versioned function. For example, the `H5Rdereference` macro can be mapped to either `H5Rdereference1` or `H5Rdereference2`. When used, the value of the `H5Rdereference_vers` compile-time version flag determines which function will be called:

- When `H5Rdereference_vers` is set to `1`, the macro `H5Rdereference` will be mapped to `H5Rdereference1`.
  `h5cc ... -DH5Rdereference_vers=1 ...`

- When `H5Rdereference_vers` is set to `2`, the macro `H5Rdereference` will be mapped to `H5Rdereference2`.
  `h5cc ... -DH5Rdereference_vers=2 ...`

- When `H5Rdereference_vers` is not set, the macro `H5Rdereference` will be mapped to either `H5Rdereference1` or `H5Rdereference2`, based on the application mapping, if one was specified, or on the library mapping.
  `h5cc ...`

At release 1.10.0, The following table lists the new API compatibility macros, function and struct mapping compile-time version flags and values, and corresponding versioned functions and struct that were introduced at HDF5 Release 1.10.0. If the application being compiled to run with any 1.10.x release was written to use any 1.8.x release of HDF5, these are the only macros you need to worry about.

Table 3: Function Mapping Options in Releases 1.10.x
Macro | `h5cc` version flag and value | Mapped to function or struct
--- | --- | ---
`H5Acreate` | `-DH5Rdereference_vers=1` | `H5Rdereference1`
`-DH5Rdereference_vers=2` | `H5Rdereference2`
`H5Fget_info` | `-DH5Fget_info_vers=1` | `H5Fget_info1` with struct `H5F_info1_t`
`-DH5Fget_info_vers=2` | `H5Fget_info2` with struct `H5F_info2_t`

At release 1.8.0, the API compatibility macros, function mapping compile-time version flags and values, and corresponding versioned functions listed in the following table were introduced. If the application being compiled to run with any 1.10.x release was written to use any 1.6.x release of HDF5, you must also consider these macros and mapping options.

Table 4: Function Mapping Options in Releases 1.8.x
Macro | `h5cc` version flag and value | Mapped to function or struct
--- | --- | ---
`H5Acreate` | `-DH5Acreate_vers=1` | `H5Acreate1`
`-DH5Acreate_vers=2` | `H5Acreate2`
`H5Aiterate` | `-DH5Aiterate_vers=1` | `H5Aiterate1` with struct `H5A_operator1_t`
`-DH5Aiterate_vers=2` | `H5Aiterate2` with struct `H5A_operator2_t`
`H5Dcreate` | `-DH5Dcreate_vers=1` | `H5Dcreate1`
`-DH5Dcreate_vers=2` | `H5Dcreate2`
`H5Dopen` | `-DH5Dopen_vers=1` | `H5Dopen1`
`-DH5Dopen_vers=2` | `H5Dopen2`
`H5Eclear` | `-DH5Eclear_vers=1` | `H5Eclear1`
`-DH5Eclear_vers=2` | `H5Eclear2`
`H5Eprint` | `-DH5Eprint_vers=1` | `H5Eprint1`
`-DH5Eprint_vers=2` | `H5Eprint2`
`H5Epush` | `-DH5Epush_vers=1` | `H5Epush1`
`-DH5Epush_vers=2` | `H5Epush2`
`H5Eset_auto` | `-DH5Eset_auto_vers=1` | `H5Eset_auto1`
`-DH5Eset_auto_vers=2` | `H5Eset_auto2`
`H5Eget_auto` | `-DH5Eget_auto_vers=1` | `H5Eget_auto1`
`-DH5Eget_auto_vers=2` | `H5Eget_auto2`
`H5E_auto_t` Struct for `H5Eset_auto` and `H5Eget_auto` | `-DH5E_auto_t_vers=1` | `H5E_auto1_t`
`-DH5E_auto_t_vers=2` | `H5E_auto2_t`
`H5Ewalk` | `-DH5Ewalk_vers=1` | `H5Ewalk1` with callback `H5E_walk1_t` and struct `H5E_error1_t`
`-DH5Ewalk_vers=2` | `H5Ewalk2` with callback `H5E_walk2_t` and struct `H5E_error2_t`
`H5Gcreate` | `-DH5Gcreate_vers=1` | `H5Gcreate1`
`-DH5Gcreate_vers=2` | `H5Gcreate2`
`H5Gopen` | `-DH5Gopen_vers=1` | `H5Gopen1`
`-DH5Gopen_vers=2` | `H5Gopen2`
`H5Pget_filter` | `-DH5Pget_filter_vers=1` | `H5Pget_filter1`
`-DH5Pget_filter_vers=2` | `H5Pget_filter2`
`H5Pget_filter_by_id` | `-DH5Pget_filter_by_id_vers=1` | `H5Pget_filter_by_id1`
`-DH5Pget_filter_by_id_vers=2` | `H5Pget_filter_by_id2`
`H5Pinsert` | `-DH5Pinsert_vers=1` | `H5Pinsert1`
`-DH5Pinsert_vers=2` | `H5Pinsert2`
`H5Pregister` | `-DH5Pregister_vers=1` | `H5Pregister1`
`-DH5Pregister_vers=2` | `H5Pregister2`
`H5Rget_obj_type` | `-DH5Rget_obj_typevers=1` | `H5Rget_obj_type1`
`-DH5Rget_obj_type_vers=2` | `H5Rget_obj_type2`
`H5Tarray_create` | `-DH5Tarray_create_vers=1` | `H5Tarray_create1`
`-DH5Tarray_create_vers=2` | `H5Tarray_create2`
`H5Tcommit` | `-DH5Tcommit_vers=1` | `H5Tcommit1`
`-DH5Tcommit_vers=2` | `H5Tcommit2`
`H5Tget_array_dims` | `-DH5Tget_array_dims_vers=1` | `H5Tget_array_dims1`
`-DH5Tget_array_dims_vers=2` | `H5Tget_array_dims2`
`H5Topen` | `-DH5Topen_vers=1` | `H5Topen1`
`-DH5Topen_vers=2` | `H5Topen2`
`H5Z_class_t` Struct for `H5Zregister` | `-DH5Z_class_t_vers=1` | `H5Z_class1_t`
`-DH5Z_class_t_vers=2` | `H5Z_class2_t`

See the HDF5 Reference Manual for complete descriptions of all API compatibility macros and versioned functions shown in Table 3 (and Table 4, if the application in question was written for a 1.6.x version of HDF5).

It is possible to specify multiple function mappings for a single application build:

`h5cc ... -DH5Rdereference_vers=1 -DH5Fget_info_vers=2 ...`

As a result of the function and struct mappings in this compile example, all occurrences of the macro `H5Rdereference` will be mapped to `H5Rdereference1` and all occurrences of the macro `H5Fget_info` will be mapped to `H5Fget_info2` for the application being built.

The function and struct mappings can be used to guarantee that a given API compatibility macro will be mapped to the desired underlying function or struct version regardless of the library or application mappings. In cases where an application may benefit greatly from features offered by some of the later APIs, or must continue to use some earlier API versions for compatibility reasons, this fine-grained control may be very important.

As noted earlier, the function mappings can only reference versioned functions that are included in the HDF5 Library, as determined by the configure flag used to build the library. For example, if the HDF5 Library being linked with the application was built with the `--disable-deprecated-symbols` option, version 1 of the underlying functions would not be available, and the example above that defined `H5Rdereference_ver=1` would not be supported.

The function mappings do not negate any available functions. If `H5Rdereference1` is available in the installed version of the HDF5 Library, and the application was not compiled with the `-DH5_NO_DEPRECATED_SYMBOLS` flag, the function `H5Rdereference1` will remain available to the application through its versioned name. Similarly, `H5Rdereference2` will remain available to the application as `H5Rdereference2`. The function mapping version flag `H5Rdereference_vers` only controls the mapping of the API compatibility macro `H5Rdereference` to one of the two available functions.

This can be especially useful in any case where the programmer does not have direct control over global macro definitions, such as when writing code meant to be copied to multiple applications or when writing code in a header file.

### Compatibility Macros in HDF5 1.6.8 and Later

A series of similar compatibility macros were introduced into the release 1.6 series of the library, starting with release 1.6.8. These macros simply alias the ‘1’ version functions, callbacks, and typedefs listed above to their original non-numbered names.

These macros were strictly a forward-looking feature at that time; they were not necessary for compatibility in 1.6.x. These macros were created at that time to enable writing code that could be used with any version of the library after 1.6.8 and any library compilation options except `H5_NO_DEPRECATED_SYMBOLS`, by always using the ‘1’ version of versioned functions and types. For example, `H5Dopen1` will always be interpreted in exactly the same manner by any version of the library since 1.6.8.

### Common Use Case

A common scenario where the API compatibility macros may be helpful is the migration of an existing application to HDF5 Release 1.10.0. An incremental migration plan is outlined here:

1. Build the HDF5 Library without specifying any library mapping `configure` flag. In this default mode, the 1.6.x, 1.8.x, and 1.10.x versions of the underlying functions are available, and the API compatibility macros will be mapped to the 1.10.x versioned functions. For example, `H5Rdereference` will be mapped to `H5Rdereference2` and `H5Gcreate` will be mapped to `H5Gcreate2`.

2. Compile the application with the `-DH5_USE_18_API` application mapping option if it was written for use with an HDF5 Release 1.8.x library (or with `-DH5_USE_16_API` if it was written for use with 1.6.x) and link with the HDF5 Library built in step 1. No changes should be required to build the application. The API compatibility macros, for example `H5Rdereference`, replace the actual function names that were used in versions of the library prior to 1.10.0. Because the application mapping overrides the library mapping, the macros will all be mapped to the 1.8.x (or 1.6.x) versions of the functions.

3. Remap one API compatibility macro at a time (or sets of macros), to use the 1.10.x versions. At each stage, use the function mappings to map the macros being worked on to the 1.10.x versions. For example, use the `-DH5Rdereference_vers=2` version flag setting to remap the `H5Rdereference` macro to `H5Rdereference2`, the 1.10.x version.

   During this step, the application code will need to be modified to change the calling parameters used with the API compatibility macros to match the number and type of the 1.10.x versioned functions. The macro name, for example `H5Rdereference`, should continue to be used in the code, to allow for possible re-mappings to later versioned functions in a future release.

4. After all macros have been migrated to the 1.10.x versioned functions in step 3, compile the application without any application or function mappings. This build uses the library mappings set in step 1, and maps API compatibility macros to the 1.10.x versions.

5. Finally, compile the application with the application mapping `-DH5_NO_DEPRECATED_SYMBOLS`, and address any failures to complete the application migration process.

HDF5 documents and links Introduction to HDF5 HDF5 User’s Guide | In the HDF5 Reference Manual H5DS H5IM H5LT H5PT H5TB Optimized H5 H5A H5D H5E H5F H5G H5I H5L H5O H5P H5PL H5R H5S H5T H5Z Tools Datatypes Fortran Compatibility Macros Collective Calls in Parallel