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]>
This commit is contained in:
@@ -70,6 +70,10 @@ the VDS item, which is marked.
|
||||
sweep files, `InvalidLayoutVersion`. This is the largest single gap.
|
||||
**Fixed 2026-09-25:** versions 1 and 2 are parsed (compact, contiguous,
|
||||
chunked via the v1 B-tree).
|
||||
- **Compound datatype version 1 array members** (found with the layout
|
||||
fix; pre-1.4 files such as `tarrold.h5`): **wrong data** — the legacy
|
||||
per-member dimensions were skipped, so an array member read as one scalar.
|
||||
**Fixed 2026-09-25.**
|
||||
- **Virtual datasets:**
|
||||
- **Wrong data:** unmapped regions read as 0 instead of the fill value.
|
||||
- `%b` printf-style source names are not expanded.
|
||||
|
||||
Reference in New Issue
Block a user