test: cover Fixed Array chunk indexes against real files

The Extensible Array bug reached a release because no fixture had more chunks than fit inline, so its data blocks were never read. The Fixed Array index had the same blind spot: nothing exercised it above a handful of chunks, and nothing reached the paged layout at all. Checked at 100, 5 000 and 200 000 chunks plus a sparse dataset that leaves whole pages uninitialised. It is correct throughout — it does keep its page-init bitmap inside the data block, which is the difference from the Extensible Array that made assuming otherwise a bug. Adding the tests so that stays true. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
2026-09-20 17:20:12 -07:00
parent 367faad7f7
commit eb196e824f
2 changed files with 83 additions and 0 deletions
@@ -27,6 +27,12 @@
  Covered now by interop tests at 4, 37, 400, 5 000 and 200 000 chunks (the
  last large enough for paged data blocks), plus sparse, gzip-filtered and
  2-D cases. Writing is unaffected; this is a read-path bug.
+- `clawhdf5-format`: the sibling Fixed Array index (fixed dimensions written
+  with `libver='latest'`) was checked against the same range and is correct,
+  including paged data blocks and sparse datasets — it really does keep its
+  page-init bitmap in the data block, where the Extensible Array does not.
+  It had no real-file coverage above the inline sizes either, so it now has
+  the same tests.

 ### Security
 - `clawhdf5-format`: **a crafted file could crash any reader through B-tree v2