R23 — hasSpaceFor overflows, and InputQuery.total overflows into a negative that sails through it #32

Closed
opened 2026-08-23 03:44:51 +00:00 by JMR-dev · 1 comment
JMR-dev commented 2026-08-23 03:44:51 +00:00 (Migrated from github.com)

Finding R23 from the overnight max-effort review (Fable lead, Opus sub-agents). Full report: scratchpad/overnight/REVIEW.md.

R23 — hasSpaceFor overflows, and InputQuery.total overflows into a negative that sails through it

severity: low
verdict: CONFIRMED
where: app/src/main/java/org/libremediaconverter/convert/OutputPublisher.kt:54; InputQuery.kt:68
scenario: bytes within ~128 MiB of Long.MAX_VALUE wraps the sum negative -> "plenty of room". Reachable half: InputQuery.total folds per-file sizes with no clamp on the sum; three 4e18 inputs produce a negative total that ConcatWorker hands to hasSpaceFor, which says yes. Not fileable as known-and-recorded: D1 mentions overflow only as item 5 of its unexecuted test list, and this is live on main regardless of the allocatable question.
evidence: Robolectric probe on unmodified main: hasSpaceFor(Long.MAX_VALUE)=true; total(3x4e18) negative -> hasSpaceFor(total)=true.
fix: Clamp and subtract — exactly StagingSpace.hasRoomFor on the parked branch. MIS-SEVERITY NOTE for D1: the clamping half of fix/allocatable-space is self-contained and does NOT depend on the blocked near-full-disk measurement; it could land alone with StagingSpaceTest's two coverage tests.
risk: None beyond arithmetic. Fully JVM-verifiable.


Cut: above — worked autonomously overnight.

🤖 Generated with Claude Code

_Finding **R23** from the overnight max-effort review (Fable lead, Opus sub-agents). Full report: `scratchpad/overnight/REVIEW.md`._ ### R23 — hasSpaceFor overflows, and InputQuery.total overflows into a negative that sails through it severity: low verdict: CONFIRMED where: app/src/main/java/org/libremediaconverter/convert/OutputPublisher.kt:54; InputQuery.kt:68 scenario: bytes within ~128 MiB of Long.MAX_VALUE wraps the sum negative -> "plenty of room". Reachable half: InputQuery.total folds per-file sizes with no clamp on the sum; three 4e18 inputs produce a negative total that ConcatWorker hands to hasSpaceFor, which says yes. Not fileable as known-and-recorded: D1 mentions overflow only as item 5 of its unexecuted test list, and this is live on main regardless of the allocatable question. evidence: Robolectric probe on unmodified main: hasSpaceFor(Long.MAX_VALUE)=true; total(3x4e18) negative -> hasSpaceFor(total)=true. fix: Clamp and subtract — exactly StagingSpace.hasRoomFor on the parked branch. MIS-SEVERITY NOTE for D1: the clamping half of fix/allocatable-space is self-contained and does NOT depend on the blocked near-full-disk measurement; it could land alone with StagingSpaceTest's two coverage tests. risk: None beyond arithmetic. Fully JVM-verifiable. --- **Cut:** `above` — worked autonomously overnight. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
JMR-dev commented 2026-08-23 04:52:52 +00:00 (Migrated from github.com)

Fixed in #48 (merged). Each fix is pinned by a mutation that was applied and reverted individually — the failure text is in the PR body. Suite 257 -> 276, 0 failures.

Fixed in #48 (merged). Each fix is pinned by a mutation that was applied and reverted individually — the failure text is in the PR body. Suite 257 -> 276, 0 failures.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: JMR-dev/LibreMediaConverter#32