Drew T
2.2 KiB
§185 — EDIT THE SIDE THAT IS CHEAP TO VERIFY, AND CHECK A TU RETYPE AT ITS USE SITES
Three TU declaration retypes were attempted this session. The pattern in what worked:
| edit | verdict |
|---|---|
func_8001ABBC declared void → s32 |
byte-neutral (sole caller discards the return) |
W16 D_80076240 → Slot16A D_80076240[] (+ its one use) |
byte-neutral |
W32 D_8007622C → s32 D_8007622C[] (+ its one use) |
byte-neutral |
s16 D_800C5328[] → s16 D_800C5328[][2] |
REFUTED — compiles at the declaration, then breaks four banked assignments in two other functions (incompatible types in assignment) |
So a TU retype is byte-neutral only if every EXISTING USE SITE still compiles unchanged. Checking the declaration proves nothing; grep the uses first, and count them. A retype that forces edits to already-banked functions is not a retype, it is a re-match of those functions.
And prefer the cheap side. Verifying a DRAFT change costs one match_one (seconds, isolated);
verifying a TU change costs a clean rebuild (minutes) and risks every function in the file. So when a
draft and its TU disagree, push the edit into the draft by default — including adopting the TU's
single-field wrapper structs (D_80076228.v = x instead of D_80076228 = x, identical bytes at
offset 0). Reserve TU edits for the cases where the draft side is provably impossible.
§185b — THE BLOCK-SCOPE extern RETYPE CAN BE LOAD-BEARING, AND THEN NOTHING ELSE WORKS.
func_80031A98 needs extern s16 D_800C5328[][2]; inside the function so every access types as a
genuine 2-D array (§164-26: outer subscript variable, inner literal, no ADDR_EXPR pseudo, per-use
inline addressing). Both escapes fail, and fail the same way — a local s16 (*t)[2] pointer variable
AND an inline ((s16 (*)[2])D_800C5328)[i][0] cast each hoist a base load (§183.3 again). C forbids
the block-scope redeclaration against the file-scope flat type, and retyping the file breaks four
banked call sites. Recorded as genuinely blocked, with the exact cost of unblocking it: retype
those four assignments and re-verify their bytes. That is a real answer, not a failure.