Joseph Ferano
c897526e47
(Ptr Enemy) already says Enemy, at compile time, in the walk. What the renderer lacked was any way to know whether the storage at the far end is still there — and an allocation registry is exactly a record of which addresses it is still true to read. So the inspector follows a live one and renders the pointee by the same walk as anything else, and names what died at a dead one. println does not, and the split is not squeamishness: spec-memory.md fixes what a printed Ptr prints, a printed line belongs to the program and has to read the same in a release build, and a release build has no registry to ask. The two callers already differ in an emitter record; they differ in one more. No address appears in the text. An address is not stable across two runs, so printing one would make a rendering depend on where the heap landed — the rule Render already follows for an allocator. What a reader wants from a dangling pointer is what died. registry.flan is one program read twice: a dev build answers for an address at the heap, arena and pool tiers, and a release build answers 0 to all of it. The arena row is the free-all Valgrind cannot see — this does not make memcheck report it, it makes the same read answerable.
