LibParseChar reads memory unconditionally under non-short-circuit Yul and(): out-of-allocation reads despite memory-safe, OOG for far-past-end cursors #38

Unit

src/lib/parse/LibParseChar.sol:19 (skipMask) and :34 (isMask).

Intent oracle

• NatSpec: skipMask "IS guaranteed never to move the cursor past the end"; isMask "If the cursor is at or past the end, the result is 0" — i.e. both are documented to handle at-or-past-end cursors by returning a value.
• assembly ("memory-safe") asserts to solc that the block only accesses memory the compiler's model allows.

Violated property

Yul and() does not short-circuit: byte(0, mload(cursor)) executes even when lt(cursor, end) is 0. Consequences:

1. When cursor >= end the load is outside any allocation (and even in range, up to 31 bytes past the string's data are read). The memory-safe annotation is violated for these accesses; a future optimizer relying on the annotation could miscompile.
2. A far-past-end cursor pays memory-expansion gas and can OOG, although the docs promise a returned value for at-or-past-end cursors.

Verified repro

LibParseChar.isMask(1 << 32, 0, 0) OOGs on ~4GB memory expansion. The existing tests deliberately avoid the region: "Limit to 16-bit values to avoid OOM reads" (test/src/lib/parse/LibParseChar.isMask.t.sol:19-20 and skipMask twin).

Triage framing

Might be intended: this is a hot-loop gas design ("we want to avoid jumps"), callers are internal parsers holding real in-range pointers, and only byte 0 of the loaded word ever influences the result — and only when in range. Might not: the memory-safe claim is load-bearing for solc, and the OOG behaviour contradicts the documented at-or-past-end contract. Found by the 2026-08-24 adversarial mutation-test campaign (mutation coverage of both functions is otherwise complete: 19/19 killed).

🤖 Generated with Claude Code