fix(format): keep the array dimensions of compound v1 members

Compound datatype version 1 carries, per member, a dimensionality and four dimension sizes (HDF5 before 1.4 had no array class). The parser skipped those 28 bytes, so a member such as `f: f32[4]` came back as a single f32 at the member's offset: the compound's size was right but its members were wrong. libhdf5 wraps such a member in an array type of the first `dimensionality` sizes and ignores the permutation; do the same, and reject a dimensionality above 4 as libhdf5 does. Only files old enough to also use layout message v1 have these, so this became reachable with the previous commit (tarrold.h5, tcompound.h5). Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
2026-09-25 21:55:31 -05:00
parent 85eb7f5ce2
commit 36356ba8a1
6 changed files with 119 additions and 2 deletions
@@ -300,6 +300,11 @@
  - Two threads reading two chunked datasets through one `File` could get each
    other's chunks (the shared chunk cache was switched between datasets
    across separate lock acquisitions). The cache is now keyed by dataset.
+  - Compound datatype version 1 members with legacy array dimensions (HDF5
+    before 1.4, which had no array class) were read as a single scalar at
+    the member's offset; they are now array members, as in libhdf5
+    (`tarrold.h5`, `tcompound.h5`). Only reachable once layout versions 1/2
+    were readable, since the files that use it are that old.
 - `clawhdf5-format` reader — errors on valid files: enum and bool datasets
  through the numeric readers; the "don't filter partial edge chunks" layout
  flag; Fletcher32 ahead of deflate (NetCDF-4's order). Unknown-message flags