From efe4c06be62b9881d807f277b4a4eb5d21ccda40 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:39:46 +0200 Subject: [PATCH] Show the chunk header does not encode the record stride All 90 two-byte windows of header[0..14] were tested: none maps to a unique stride across every group. There is no simple two-byte field to read the record size from. The stride must therefore come from the offset table, by differencing the first two tagged offsets, which is what the parser already does. This validates that choice as more than convenience. Given three chunks sharing one header with three different strides, a dispatch that assumed "header implies size" would be wrong for the whole type-ID coverage on at least one layout. Reading the stride from the offsets is the only interpretation consistent with every measurement so far. Negative result recorded deliberately: it rules out a whole family of hypotheses (stride encoded in the header) rather than narrowing one. --- docs/formats/core-data-regions.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index ab7f5ca..5d1d65d 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -875,6 +875,19 @@ This does not change the earlier conclusion that 63 of 64 headers imply one stride -- that remains 63 of 64 -- but the mapping is not a bijection and should not be used as one. +**The header does not encode the stride.** All 90 two-byte windows of +`header[0..14]` were tested: none maps to a unique stride across every group. +So there is no simple two-byte field to read the record size from, and the +stride must come from the offset table, as the parser already does, by +differencing the first two tagged offsets. + +That is the right implementation anyway, and this makes it more than a +convenience: given three chunks sharing one header with three different +strides, any dispatch that assumed "header implies size" would be wrong for +1,123 chunks' worth of type coverage on at least one layout. Reading the +stride from the offsets is the only interpretation consistent with all the +measurements. + **The ASCII reading is confirmed as a type tag.** Grouping by header bytes 9 and 13: