fix(buffer): guard capacity doubling against Int overflow - #3822
Draft
bobzhang wants to merge 1 commit into
Draft
Conversation
Buffer::grow_if_necessary doubled capacity until it covered the requirement. Once capacity passes 2^30, `space * 2` overflows: a power-of-two capacity wraps to INT_MIN and then sticks at 0, looping forever (writes needing >1 GiB hung); non-power-of-two capacities bounce through wrapped values before accidentally terminating on whatever positive value the wraparound lands on. Extract the capacity computation into a pure grow_capacity helper that falls back to exactly `required` on the first overflowing doubling. Below the overflow threshold the doubling sequence is unchanged; past it, the buffer now allocates the exact requirement instead of hanging (power-of-two case) or a wraparound-determined size (other cases). Whitebox tests cover the normal doubling path and both overflow boundary cases without allocating memory. Reviewed by Codex CLI (codex-cli 0.144.1) in two rounds: the first rejected an overbroad equivalence claim and asked for CI-safe boundary tests via a pure helper; re-review: "Approved. grow_capacity correctly detects overflowing doubles... the commit message accurately scopes the behavior difference." Signed-off-by: Codex CLI <codex@openai.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Collaborator
Coverage Report for CI Build 5184Coverage increased (+0.002%) to 91.27%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Buffer::grow_if_necessarydoubled capacity until it covered the requirement. Once capacity passes 2³⁰,space * 2overflowsInt:INT_MIN, then sticks at0 → 0 → ...— writes needing more than ~1 GiB of buffer hung forever;Fix
The capacity computation moves into a pure
grow_capacity(current, required)helper that falls back to exactlyrequiredon the first overflowing doubling. Below the overflow threshold the doubling sequence is byte-for-byte unchanged; past it, the buffer allocates the exact requirement instead of hanging or trusting wraparound.Whitebox tests (
buffer/grow_wbtest.mbt) pin the normal doubling path and both overflow boundary cases — without allocating memory, so they're CI-safe.Review
Reviewed by Codex CLI (codex-cli 0.144.1) in two rounds. Round 1 rejected the initial version: it disproved my "identical capacity for all previously-terminating inputs" claim with the 11 → 1.5 G wraparound counterexample, confirmed the power-of-two hang (2³⁰ → INT_MIN → 0 → 0), audited that no other grow path in
buffer/shares the bug, and demanded CI-safe tests via a pure helper. All applied. Round 2: "Approved.grow_capacitycorrectly detects overflowing doubles... the commit message accurately scopes the behavior difference."Signed-off-by: Codex CLI codex@openai.com
Validation
moon checkclean,moon fmtapplied, no.mbtichangesmoon test: 6717 passed, 0 failed (buffer 98/98, incl. 2 new boundary tests)🤖 Generated with Claude Code