BFM-decomp/cookbook/C0308.md

What I could not verify

• func_80184458 (ov_SC04_005): could not independently re-verify the reported 41-vs-40-instruction delta between the pass-by-address and pass-by-value spellings — only the banked target is on disk, not the rejected counterfactual draft. The underlying mechanism (§229's declaration corollary) is already general and doesn't depend on this one instance to stand.

• func_80181600 (ov_SC01_009): accepted the "missing TU decl → implicit-int → extend-tell silently drops the promotion pair" claim on the strength of §172b-1's already-proven mechanism plus the already-documented standalone-compile fact; did not independently re-derive the implicit-int interaction from gcc internals in the time available.

• func_800CAE74 (md_MAIN_031) — reviewer claim did NOT survive checking. The original note's claim that the target's dataflow is a special "parameter reassignment" idiom (arg1 = *(arg1+0xC) parking the incoming register for a later tail call) does not match the actual banked C, which uses an ordinary fresh local while arg1 itself stays untouched and lives in $s2 purely because it is read across a later jal — ordinary call-crossing liveness (§167-21/§76 family), not a distinct mechanism. The genuinely new content of this candidate (pointer-vs-integer cursor typing selecting sltu/slt) was separated out and promoted as its own NEW section above.

• func_800CBCD4 (md_MAIN_031) — reviewer claim did NOT survive checking. The original note's claim 5 ("the 4th else copy needs its own fresh temp so its value lands in v1 like the target's lhu v1/sh v1 pair") is factually wrong: the actual 4th else-copy in the target .s uses lhu $v0/sh $v0, not $v1. The rest of the note resolves to already-covered law (§193-H, §247), so this candidate was rejected outright rather than partially promoted.

• func_80186AD0 (ov_SC06_032): the note's claim that a register __asm__("$4") pin on the copy source deletes the copy instruction and drops the delay-slot fill could not be checked — the final banked code uses a plain local (s32 a; a = s0;), not the pinned spelling the note describes, so there is no byte evidence for that half of the claim in the current tree. Only the statement-order half (verified) was promoted.

• func_800CB428 (md_MAIN_031): the note's claim that a literal do-while + break spelling would have compiled to a rotated/duplicated-header shape (vs the goto-based loop actually used) is a counterfactual about an untried spelling and cannot be checked against the banked bytes; not promoted, though it is consistent with the already-documented §17775/F5 "goto/label loop is invisible to loop.c" fact.

Harness-defect flags (not idioms, called out per the assignment's request): three candidates (func_800CAFE4, func_8017F39C, func_800CBC14) describe repeated non-banking of a body the submitting agent had already proven byte-correct multiple ways, with the residual explicitly attributed to harness/gate state rather than source — func_8017F39C in particular flags a suspected same-name binary-registration collision (a homonym in ov_SC01_009 sharing the symbol) as the likely cause if the non-bank persists. All three resolve to already-documented classes (§42b's stale-object gate trap, §238's overlay-homonym trap) rather than new gaps, but are flagged here in case the underlying gate behavior itself — not just the drafting-side diagnostic — merits a maintenance look.