HDF version 4.3.1 released on 2025-06-30
====================================================

INTRODUCTION

This document describes the differences between this release and the
HDF 4.3.0 release.  It is written for people who are familiar with
previous releases of HDF and wish to migrate to this version of HDF.

Note that the HDF4 documentation will be updated at the time of
each final release and can be found on the HDF4 support page at:

    https://portal.hdfgroup.org/display/HDF4

The official HDF4 releases can be obtained from:

    https://portal.hdfgroup.org/downloads/index.html

If you have any questions or comments, please send them to the HDF Help Desk:

     help@hdfgroup.org

CONTENTS

- New features and changes
  -- Configuration
  -- C Library
- Bugs fixed since HDF 4.3.0
  -- Configuration
  -- Library
- Documentation
- Platforms Tested
- Known problems


New features and changes
========================
    Configuration:
    -------------
      None

    C Library:
    -------------
      None


Bugs fixed since HDF 4.3.0
===========================

    Configuration:
    -------------
      None

    Library:
    -------
    - Fixed various uninitialized memory occurrences

      Valgrind reported
        "Conditional jump or move depends on uninitialised value(s)"
      errors in some of the jpeg tests even though the buffers were initialized
      properly prior to calling the JPEG read function.  This was due to some
      optimizations/alignments by the JPEG library.

      Using the environment variable JSIMD_FORCENONE=1 to disable SIMD (Single
      Instruction Multiple Data) optimizations will help removing the errors,
      if desired.  However, because these optimizations take advantage of hardware
      capabilities to speed up JPEG compression and decompression, disabling them
      might cause the opposite effect.

      Addresses GH-818

    - Fixed memory leaks in Vgroup and Vdata APIs

      The code that destroys the atom groups for Vdatas and Vgroups was placed
      after the free lists had already been freed, resulting in more released
      memory being added to the free lists, which were never freed, again.  Fixed.

      Addresses GH-819

    - Fixed memory leaks in SD API

      The SD API internal code contained some memory leaks.  This is now fixed.

      Addresses GH-825

    Utilities:
    ---------
    - Fixed hdp to display variables with rank = 0 properly

      Previously the tool did not handle variables with rank = 0 correctly.
      Thus, it simply skipped printing these variables.

      Addresses HDFFR-1293


Documentation
=============


Platforms Tested
================
This version has been tested in the following platforms:

(Format:
   uname -s, uname -r
   uname -v, uname -p, uname -m)

    Linux 6.7.4                      GNU gcc (GCC) 13.2.1
    Fedora 39                        Clang version 17.0.6
                                     
    Linux 5.15.0                     GNU gcc (GCC) 11.3.0, 11.4.0, 12
    Ubuntu SMP x86_64 GNU/Linux      GNU Fortran (GCC) 11.3.0, 12
    Ubuntu 22.04                     Clang version 14.0.0
                                     Intel OneApi 2023.1.0, 2023.2.0, 2024.0
                                     Nvidia nvc 23.9
                                     AOCC 4.1.0, Clang 16.0.3
                                     Mingw, GNU GCC 10.0.0
                                     (cmake and autotools)

    Linux 5.13.0                     GNU gcc (GCC) 9.4.0
    Ubuntu SMP x86_64 GNU/Linux      GNU Fortran (GCC) 9.4.0
    Ubuntu 20.04                     Clang version 10.0.0
                                     Intel OneApi 2023.1.0
                                     (cmake and autotools)

    Linux 4.18.0-348.7.1.el8_5       gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
    #1 SMP x86_64 GNU/Linux          GNU Fortran (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4)
    CentOS8                          clang version 12.0.1 (Red Hat 12.0.1)
                                     Intel OneApi 2023.1.0
                                     (cmake and autotools)

    Linux 3.10.0-1160.36.2.el7.ppc64 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
    #1 SMP ppc64 GNU/Linux           g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
    (echidna)                        GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
                                     IBM XL C/C++ V13.1
                                     IBM XL Fortran V15.1f
 
    Linux 3.10.0-327.18.2.el7.x86_64 GNU C (gcc) and Fortran (gfortran) compilers:
    #1 SMP x86_64, GNU/Linux             Version 4.8.5 20150623 (Red Hat 4.8.5-4)
    (jelly/moohan)                       Version 5.3.0, 6.3.0, 7.2.0, 8.3.0, 9.1.0, 10.2.0
                                     Intel(R) C (icc) and Fortran (ifort) compilers:
                                        Version 17.0.0.098 Build 20160721
                                     pgcc and pgf90 17.10-0 64-bit target
                                         on x86-64 Linux -tp haswell

    Linux 2.6.32-754.11.1.el6.x86_64  gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
    #1 SMP, x86_64                    GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
    (platypus)                        icc (ICC) 17.0.0.098 Build 20160721
                                      ifort (IFORT) 17.0.0.098 Build 20160721
                                      pgcc and pgf90 17.10-0 64-bit target
                                         on x86-64 Linux -tp nehalem

    macOS Sonoma 14                  Apple clang version 15.0.7
    Darwin 23.2.0 arm64              Clang 17.0.0

    macOS Ventura 13.6.4             Apple clang version 15.0.0
    Darwin 22.6.0 x86_64

    macOS Monterey 12                Apple clang version 14.0.0
    Darwin 21.6.0 x86_64             gfortran GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
    (philo)                          Intel icc/icpc/ifort version 2021.10.0 20230609

    macOS Apple M1 11.7.3            Apple clang version 13.0.0 (clang-1300.0.29.30)
    Darwin 20.6.0 arm64              gfortran GNU Fortran (Homebrew GCC 12.2.0) 12.2.0
    (macmini-m1)                     Intel icc/icpc/ifort version 2021.8.0 20221120

    macOS Big Sur 11.7.3             Apple clang version 12.0.5 (clang-1205.0.22.9)
    Darwin 20.4.0 x86_64             gfortran GNU Fortran (Homebrew GCC 12.2.0) 12.2.0
    (bigsur-1)                       Intel icc/icpc/ifort version 2021.7.1 20221019

    Windows 10 x64                  Visual Studio 2019 w/ clang 12.0.0
                                        with MSVC-like command-line (C/C++ only - cmake)
                                    Visual Studio 2019 w/ Intel C/C++/Fortran oneAPI 2024 (cmake)
                                    Visual Studio 2022 w/ clang 17.0.1
                                        with MSVC-like command-line (C/C++ only - cmake)
                                    Visual Studio 2022 w/ Intel C/C++/Fortran oneAPI 2024 (cmake)

Known problems
==============
o  The Fortran interface does not work on 64-bit systems as it stores addresses
   in memory as Fortran INTEGER values, which are typically 32-bit. The
   Fortran interface is currently disabled by default due to this. It should
   only be enabled on 32-bit systems.

o  Builds with the autotools option --enable-hdf4-xdr fail on Solaris and
   on IBM ppc64 with the xlc compiler.  The option should not be used on
   those platforms.

o  A number of tools and tests fail to free small amounts of memory if they
   are just going to exit anyway.  This doesn't appear to be a memory leak
   in the core library.  We're planning to fix these leaks in future releases,
   likely by modifying these tools to have a single point of return, where
   resource cleanup will be carried out. 

o  CMake files do not behave correctly with paths containing spaces.
   Do not use spaces in paths because the required escaping for handling spaces
   results in very complex and fragile build files.
   ADB - 2019/05/07

o  Several Fortran examples print "^@" when displaying strings (for example,
   names of the attributes). This happens because Fortran application
   doesn't know the length of the strings passed from the C library.
   EIP - 2015-01-11, HDFFR-1477

o  CMake fails to set the full path to the install location on Windows:
    The configuration file for examples, HDF4_Examples.cmake, must be updated
    with the correct value by editing the file or using the INSTALLDIR option.
    This issue is because of spaces in the path.
   ADB - 2014/02/03

o  CMake "make install" fails installing the tools:
    Use CPack to create an install package.
   ADB - 2014/02/03

o  On IBM PowerPC 64, hdftest fails when gcc 4.4.6 is used with -O3 optimization
   level.

o  When building on Linux/UNIX platforms, the szip shared library files must
   be in the system library path.  This can be done by adding a link to
   the libsz.* files in the /usr/lib folder or by adding the library
   location to the LD_LIBRARY_PATH environment variable.
      Ex. export LD_LIBRARY_PATH=path_to_szip_lib:$LD_LIBRARY_PATH
   Optionally, one can use the static szip library files by adding '-static'
   to the CFLAGS environment variable.

o  Existing data written by an HDF4 Library prior to HDF 4.2r2:
   When a one-dimensional SDS and a dimension scale have
   the same name, subsequent accesses to the dimension scale or to the
   SDS might produce undesired results because the libraries could not
   distinguish between the two objects.  In the case of writing, data
   might even be corrupted.  For example, SDS data might be written to a
   dimension variable or vice versa. (bugzilla #624)

   HDF4 Library Releases 4.2r2 and later make a distinction between an SDS
   and a dimension variable.  However, as with older versions, these recent
   versions are unable to detect such conflicts in files created by earlier
   releases.  It is therefore STRONGLY recommended to check for such name
   duplication before working with data created with a pre-4.2r2 library.

   The functions SDgetnumvars_byname and SDnametoindices are provided
   to help detect such name conflicts and select the correct object to
   access, respectively; see the HDF Reference Manual entries for
   further details.
   FB - 2009/01/26
   BMR - revised 2011/06/24

o  N-bit compression is not supported with Fortran APIs.

o  Using both fill-value and compression on SD datasets does not work.

o  When using PGI compilers, make sure that the JPEG library is also compiled
   with a PGI C compiler; linking with a JPEG library built with gcc causes
   JPEG library tests to fail.  To bypass the problem:

       x Set LIBS flag to $PGI_JPEG_INSTALL_DIR/lib/libjpeg.a
         where $PGI_JPEG_INSTALL_DIR points to the installation directory
         for the PGI-compiled JPEG library:

         setenv LIBS $PGI_JPEG_INSTALL_DIR/lib/libjpeg.a

       x Use the --with-jpeg=$PGI_JPEG_INSTALL_DIR configure flag to
         configure with the PGI-compiled JPEG library:

         ./configure --with-jpeg=$PGI_JPEG_INSTALL_DIR --with-zlib....

o  In order for the API SDgetdatasize to get the correct compressed size
   of the data, the dataset needs to be closed (SDendaccess) or read
   (SDreaddata) after being written and before SDgetdatasize is called.
   BMR - 2008/11/22

