ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Resolve the colliding header: three types share 16 bytes

Browse Source 
Header 7542eff271b522a79e45348cca4509ff was reported with three strides, 76, 92
and 104. It is not one type with a variable stride, and not a misparse.

It appears three times per level, always with record count 9, always in the
same order at the same offsets within the region:

  offset   stride  count  first  last
  863842      92      9     928  1640
  867554      76      9     912  1520
  872866     104      9    1000  1832

The offsets are 3712 apart each time and the strides differ, so these are three
separate chunks sharing 16 header bytes.

Consequence for the type ID: 64 distinct headers for 66 distinct record
layouts, not 64 for 64. The header is nearly a type ID but does not uniquely
determine the layout. Not excluded: a distinguishing byte sits outside the 16
captured, or the layout varies within a type.

This does not change "63 of 64 headers imply one stride", which remains true,
but the mapping is not a bijection and should not be used as one. Worth
checking before the parser is extended to dispatch on header alone.
This commit is contained in:
ReaperOfVeriod
2026-10-11 04:37:25 +02:00
parent 4c4175de7f
commit 1d84562e88
1 changed files with 27 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/formats/core-data-regions.md
+27 -3
View File
@@ -847,9 +847,33 @@ every level.
**63 of the 64 headers imply exactly one stride.** So header to record layout
is very nearly a function: the type determines the record size.
The single exception is header `7542eff271b522a79e45348cca4509ff`, which
appears with three strides, 76, 92 and 104. Either three types share a header,
or one of the three is a misparse. Not resolved.
**Resolved: the single exception is three types sharing a header.**
Header `7542eff271b522a79e45348cca4509ff` was reported with three strides, 76,
92 and 104. It is not one type with a variable stride, and not a misparse.
It appears **three times per level**, always with record count 9, always in the
same order and always at the same offsets within the region. On level 0 and on
every other level checked:
| offset | stride | count | first offset | last offset |
|---|---|---|---|---|
| 863842 | 92 | 9 | 928 | 1640 |
| 867554 | 76 | 9 | 912 | 1520 |
| 872866 | 104 | 9 | 1000 | 1832 |
The offsets are 3,712 apart each time and the strides differ, so these are
three separate chunks that happen to share 16 header bytes.
**Consequence for the type ID.** 64 distinct headers for 66 distinct
record layouts, not 64 for 64. The header is *nearly* a type ID but does not
uniquely determine the layout: whatever distinguishes these three is not in the
16 bytes the header captures. Candidates not excluded: a distinguishing byte
sits outside the 16 captured, or the layout varies within a type.
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 ASCII reading is confirmed as a type tag.** Grouping by header bytes 9
and 13: