fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: MCOL's u16 entries do not index the point block -- the bound-check was a false positive

Browse Source 
Two tests. Counts modulo 3 are spread across all three residues (639/2063/1786),
so the u16 array is not a triangle list. And a B record is reached through a
specific cell, so a point it references should lie in that cell -- referenced
points score 0.79% against a 0.48% random-point control. Chance.

The contrast is the point. One section earlier the same u16 entries scored
18379/18379 (100%) on 'are these valid point indices'. I flagged that at the
time as the weak bound-check and recorded it as consistent rather than as a
finding. The caution was right: the powered version of the same question now
returns chance, and had the 100% been written up as the decode this page would
carry a confident false statement about MCOL's geometry.

Fifth appearance of the pattern across REGN and MCOL and the first time both
halves have been run on the same field, so the page now states it plainly: a
bound-check asks whether something could be an index, and the answer is set by
the size of the target collection rather than by the field's meaning.

Datum for the next attempt: the maximum u16 is consistently about 0.75x the
point count (923/1232, 1019/1360, 1163/1552, 59/80), too consistent to be
coincidence and not explained.
This commit is contained in:
Sylpheed RE agent
2026-08-26 08:52:44 +00:00
parent 8c57c0e621
commit 3274ee6d8e
1 changed files with 49 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
docs/re/structures/mcol-collision.md
View File

@@ -234,6 +234,52 @@ evidence.)
which is the same shape as `REGN`'s `cell → item → refs → geometry`, as the two
formats' shared header and shared count-1 convention already suggested.
❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain),
what the indexed points form — triangles would want n divisible by 3 — and the
44-vs-4 488 accounting is exact, so there is no second pointer species to find.
❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain).
What the `u16` entries index is **not** the point block — see immediately below.
## ❌ The `u16` entries do NOT index the point block — and the weak test said they did
**2026-08-26.** Two tests, and the contrast between them is the point of this
section.
**Not a triangle list.** If the `u16` array held triangle corners, every count
would be divisible by 3. Counts modulo 3 across all objects:
n % 3 == 0 639 n % 3 == 1 2 063 n % 3 == 2 1 786
Spread across all three residues. Refuted.
**Not cell-local either.** A B record is reached *through* a specific cell, so a
point it references should lie in that cell. With a random-point control:
| | |
|---|---|
| referenced point inside the cell that reached it | 142 / 17 871 = **0.79 %** |
| a random point inside that cell (control) | 85 / 17 871 = **0.48 %** |
Chance. So whatever the `u16`s address, it is not the `0x5C` point block in any
spatially meaningful way.
### ⚠️ This is the bound-check hazard caught in the act
One section above, the same `u16` entries scored **18 379 / 18 379 (100 %)** on
"are these valid `0x5C` point indices". I flagged that at the time as the weak
bound-check rather than evidence, and recorded it as *consistent* rather than as
a finding. **That caution was correct**: the powered version of the same question
now returns chance.
This is the fifth appearance of the pattern across `REGN` and `MCOL`, and the
first time both halves have been run side by side on the same field, so it is
worth stating exactly:
> A bound-check asks *"could this be an index?"*. Almost always, yes — the answer
> is set by how large the target collection is, not by whether the field means
> anything. The powered version asks *"does the thing it points at make sense
> where it was reached from?"*, and only that version can be wrong.
Had the 100 % been written up as the decode, this page would now carry a
confident and false statement about `MCOL`'s geometry.
❔ What the `u16`s index is open. A datum for the next attempt: the maximum
`u16` is consistently ≈ **0.75 ×** the point count (923/1 232, 1 019/1 360,
1 163/1 552, 59/80) — too consistent to be coincidence, and not explained.