How would you judge whether rewriting a binary-protocol parser under a compile-time ownership discipline will actually close its defect tracker?

This is a judgment call, so the answer an interviewer is listening for is a method with numbers in it, not a preference. The failure mode is arguing about the discipline in the abstract; the move is to make the existing defect record decide. ## Step one: classify the tracker Take the open rows plus everything closed in the last year or two — closed rows matter because they measure where the effort went, not just where it is stuck. Sort into buckets and count: | Bucket | Example row from a parser | Does the rewrite close it? | |---|---|---| | Validity of access | read of a frame body after its block was released | yes, by construction | | Exactly-once release | double release of a decode buffer on an error path | yes, by construction | | Interior reference | stale reference into a buffer the parser had resized | yes, by construction | | Accidental leak on an error path | release skipped on an early return | yes, through scope-bound release | | Deliberate retention | decoded frames accumulating in a session map | no | | Protocol logic | a length prefix mis-signed, a malformed frame accepted | no | | Concurrency beyond aliasing | a lock held across a slow call | no | The first four rows are the whole prize. If they are three percent of the record, the language argument has lost regardless of its merits; if they are half of it, and especially if they have caused incidents rather than tickets, the case is strong on its own. ## Step two: price the other side honestly 1. **Re-expressing what aliasing used to do.** A parser that handed out overlapping mutable views of one input buffer has to be restructured, typically into index ranges or a single writer with borrowed readers. That work is real and it lands in the hardest part of the codebase. 2. **The unchecked surface.** Wherever the parser meets a foreign boundary or externally provided memory, the guarantee is asserted by hand. Count those sites before, not after. 3. **A changed failure shape.** Where the old parser would have read past a buffer and produced a wrong answer, a bounds-checked one stops deterministically. That is usually an improvement, but it converts silent wrongness into visible unavailability, and the operational plan has to say which the service prefers. 4. **People.** The learning curve is concentrated in exactly the engineers who currently keep the parser alive. ## Step three: consider the cheaper moves that close part of the same bucket - Attach release to scope exit and wrap raw handles in guard types within the existing code; this closes most accidental error-path leaks without a rewrite. - Route all buffer access through one checked container abstraction, which closes a large share of interior-reference defects. - Build a test configuration with heavy runtime memory checking, which finds the same class of bug late instead of preventing it — cheaper, weaker. - Rewrite only the frontier that touches untrusted input, and leave the internal stages alone. The incident-weighted benefit is usually concentrated there anyway. ## Step four: state the decision as a bet A defensible answer sounds like: *these four classes are twelve of our thirty-one open rows and three of our four incidents; rewriting the frontier closes them and takes one quarter; the remaining nineteen rows are logic and retention and we keep owning them either way.* The number that makes the decision is the class mix, weighted by incident severity, and the code's remaining lifetime — a parser due for replacement in a year never earns the rewrite, no matter how the buckets fall. The pitfall to name out loud: a rewrite closes a class of defects and simultaneously opens a fresh round of ordinary new-code bugs in a component that was battle-hardened. Preserving the old parser as a differential oracle, replaying captured traffic through both, is how that cost is kept down.