mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-29 07:10:32 -04:00
3e6c364cd8
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.