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

re: sweep my own crates for fallbacks that fabricate a quantity

Browse Source 
The mirror of sylpheed-port's sweep after their exit_ramp_units catch, where a
refuted 24.0 survived in a `get(..., 24.0)` fallback because the authored entry
had been deleted as progress and the deletion was a no-op.

112 fallback sites across sylpheed-formats and sylpheed-cli. 64 supply 0, false,
empty or Default -- sentinels asserting nothing. Of the 48 remaining most are
pass-through or an extent. Positive control: the filter found media.rs:314
unwrap_or(anchor), the voice-region start fallback landed earlier this session,
so the detector finds a known case rather than only reporting absence. The
mesh.rs cluster (1.0, 0.85, 0.5, 0.70, 0.45) is env-var tunables with defaults
documented in xbg7-mesh.md.

ui_layout.rs, the crate the port pins, has 8 sites; 6 sentinel or pass-through
and 2 that could fabricate a quantity. Both fabricate a value that is
LEGITIMATE, which is worse than the port's conspicuous 24.0:

  :695  unwrap_or((DESIGN_W, DESIGN_H)) -- 1280x720, which is what every real
        screen states, so no parser output can distinguish read from invented.
        MEASURED: it fires 0 times in 965 builds disc-wide, so design_w/design_h
        is read and the port can rely on it.

  :1681 kf.time.unwrap_or(0) in the serialiser -- 0 is a real keyframe time
        (pose 0's time IS 0). Unreachable today under the corrected record
        layout, the same status as their exit_ramp_units branch, but a
        fabricated 0 would be indistinguishable from a real one.

The measuring instrument failed its own control first: a version reading EVERY
RATC child reported all 965 builds stating a non-standard design size
(GP_TUTORIAL 12x3), where `screen list` prints 1280x720 for every one -- a T8aD
sprite header read at +0x18 is garbage that passes the range test. Filtered to
the .rat records, it reproduces screen list exactly.

METHOD: a fallback default is an authored value no reader can see, and the
dangerous ones are IN-RANGE -- the only way to know is to count how often they
fire, which no parser output reveals.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 15:06:15 +00:00
parent 7fa51e626f
commit 61dbc5cca5
3 changed files with 156 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/re/METHOD.md
View File

@@ -284,6 +284,31 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
across 105 units against edges at 78. The sweep was luck; the entry is here so
the next one is not.
* **A fallback default is an authored value that no reader can see** — and the
dangerous ones are **in-range**. `sylpheed-port` found `exit_ramp_units`
defaulting to **24.0**, the exact constant this corpus had *refuted*: the
authored entry had been deleted as progress, and a
`timing.get("exit_ramp_units", 24.0)` made the deletion a no-op, in the one
place a reader checking `authored/` would never look. **Deleting a value does
not remove it if something supplies it silently.**
⚠️ Their 24.0 was at least conspicuous. Sweeping this side for the same shape
([`data/fallback-fabrication-sweep.txt`](data/fallback-fabrication-sweep.txt))
found 112 fallback sites, of which two in the pinned `ui_layout.rs` could
fabricate a quantity — and **both fabricate a value that is legitimate**:
`(1280, 720)`, which is what every real screen states, and `kf.time.unwrap_or(0)`,
where 0 is a real keyframe time (pose 0's time *is* 0). An in-range fallback
cannot be caught downstream by inspecting the output, because the output looks
exactly like the true case. The only way to know is to **count how often it
fires**: measured, the design-size fallback fires **0 times in 965 builds**, so
that number is read rather than invented — which could not have been established
from any parser output.
Sweep for these by listing every fallback and asking *"does this supply a
quantity, or a sentinel?"* — 0/empty/`Default` and pass-throughs assert nothing;
a literal that could pass for a measurement is the hazard. Build the sweep so it
finds a **known** case as its positive control.
## Runtime / emulator
* **Look at the PNG** — and check its dimensions.

68
docs/re/data/fallback-fabrication-sweep.txt Normal file
View File

@@ -0,0 +1,68 @@
# Fallbacks that could FABRICATE a quantity, in sylpheed-formats + sylpheed-cli.
# 2026-08-30. The mirror of sylpheed-port's sweep of their own tree.
#
# 112 fallback sites (unwrap_or / unwrap_or_else / unwrap_or_default /
# serde(default)). 64 supply 0, false, empty or Default -- sentinels that assert
# nothing. Of the 48 remaining, most are pass-through (unwrap_or(s),
# unwrap_or(name)) or an extent (unwrap_or(bytes.len())), which are identity.
#
# POSITIVE CONTROL: the filter found media.rs:314 unwrap_or(anchor) -- the
# voice-region start fallback landed earlier this session -- so the detector
# finds a known case rather than only reporting absence.
#
# mesh.rs 1077/1084/1099/1106/1139/1177 (1.0, 0.85, 1, 0.5, 0.70, 0.45) are
# env-var tunables (XBG7_EDGE_CAP etc.) with defaults documented in
# structures/xbg7-mesh.md. Knobs, not measurements. Out of the menu lane.
#
## ui_layout.rs -- the crate the port PINS. 8 sites; 6 sentinel or pass-through;
## 2 could fabricate a quantity:
#
# :695 unwrap_or((DESIGN_W, DESIGN_H)) -> MEASURED BELOW: never fires
# :1681 kf.time.unwrap_or(0) -> unreachable today; note below
#
## Does the design-size fallback ever fire? Disc-wide.
## instrument: examples/design_size_fallback.rs
## CONTROL: it must reproduce screen list's 1280x720 for every build.
## A first version read EVERY RATC child and FAILED that control -- it
## reported all 965 builds stating a non-standard size (GP_TUTORIAL 12x3),
## because a T8aD sprite header read at +0x18 is garbage that passes the
## range test. Filtered to the .rat records, the control passes.
#
GP_BUNK.pak 8 read 0 FABRICATED
GP_CHALLENGE.pak 78 read 0 FABRICATED
GP_DEBRIEFING_PILOTLOG.pak 18 read 0 FABRICATED
GP_DIALOG.pak 105 read 0 FABRICATED
GP_GAMEOVER.pak 10 read 0 FABRICATED
GP_HANGAR_ARSENAL.pak 390 read 0 FABRICATED
GP_LEADERBOARD.pak 4 read 0 FABRICATED
GP_MAIN_GAME_D2D.pak 18 read 0 FABRICATED
GP_MAIN_GAME_E2D.pak 18 read 0 FABRICATED
GP_MAIN_GAME_F2D.pak 18 read 0 FABRICATED
GP_MAIN_GAME_I2D.pak 18 read 0 FABRICATED
GP_MAIN_GAME_J2D.pak 18 read 0 FABRICATED
GP_MAIN_GAME_S2D.pak 18 read 0 FABRICATED
GP_MISSION_LOG.pak 4 read 0 FABRICATED
GP_MISSION_SELECT.pak 66 read 0 FABRICATED
GP_MOVIE_THEATER.pak 56 read 0 FABRICATED
GP_OPTIONS.pak 14 read 0 FABRICATED
GP_PAUSE_MENU.pak 6 read 0 FABRICATED
GP_READY_ROOM.pak 60 read 0 FABRICATED
GP_SAVE_LOAD.pak 18 read 0 FABRICATED
GP_STAGE_CLEAR.pak 4 read 0 FABRICATED
GP_SYSTEM.pak 2 read 0 FABRICATED
GP_TITLE.pak 12 read 0 FABRICATED
GP_TUTORIAL.pak 2 read 0 FABRICATED
965 builds state a design size, 0 get the 1280x720 FALLBACK
0 builds state something other than 1280x720
# So design_w/design_h is READ, not fabricated: 965 of 965 builds state it
# explicitly and every one states 1280x720. The port can rely on it.
#
# The remaining site, ui_layout.rs:1681, serialises kf.time.unwrap_or(0) when
# writing a bundle back. `time` is still Option<u32> (line 130). Under the
# corrected record layout every pose is timed, so this cannot fire today -- the
# same status as the port's exit_ramp_units branch. What makes it worse than
# theirs if it ever did: their fabricated value was 24.0, a conspicuous magic
# number. Mine is 0, which is a LEGITIMATE keyframe time -- pose 0's time really
# is 0 -- so a fabricated one would be indistinguishable from a real one in any
# output. An in-range fallback cannot be caught downstream.