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

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

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.