Files
BFM-decomp/tools
Drew T 3e6c364cd8 feat(phase-29): T73 — items 1+2: ARITY class resolved, audit learns §113; DECLS is the last value
ITEM 1 (call-vs-address re-check). My first detector counted the DECLARATIONS as calls, so every
function looked "called". Stripping `extern ...;` first gives the real split: func_80144B14 is
ADDRESS-TAKEN only (full retype — done in T72, 137/137); func_8013BD34 / func_8014358C /
func_8017D808 are genuinely CALLED and need §99.

§99 applied to all three -> R22 clean-fleet 140 passed, 0 failed of 140, byte-neutral.

SWEEP YIELD: ZERO, and recorded as such. func_8013BD34's family swept 0/136 — exactly as predicted
when I switched T72's probe off it (its def lives in ov_SC07_010_o0.c and _o0 families sweep ~1/137).
func_8014358C has no family as exemplar; func_8017D808's family is 1 member with an unbanked
exemplar. The §99 fixes are correct and byte-neutral but unblock nothing today.

ITEM 2: called_in_headers() strips declarations, treats `fn(` as a call and `&fn` as not; arity_ok is
now "arity matches OR the macro never calls it" (§113). Verified against all four.

THE AUDIT AFTER BOTH — 28 findings (from 61):
  DECLS  9 fns  141 stubbed binaries   <- the only class with value left
  SAFE  13 fns   15
  ARITY  3 fns    0                    <- §99 cleared the stub-bearing ones
  §85    3 fns    0
func_80147364 is 137 of those 141, and is item 3.
2026-07-29 00:42:40 -06:00
..