Invalid characters: silent success with a garbage value inside the last-77-digit window, ParseDecimalOverflow beyond it #44

Unit

src/lib/parse/LibParseDecimal.sol:49-51 (main loop) and :82-93 (leading-zeros-only loop).

Intent oracle

NatSpec: "DOES NOT check that the string contains valid decimal characters. You can use LibParseChar.skipMask to easily bound some valid decimal characters." So garbage-in is documented. The finding is about the SHAPE of the garbage-out.

Violated property / behaviour

Handling of the same invalid byte depends on its position:

• Inside the last-77-digit window the unchecked assembly wraps byte - '0': " 1" (space, one) returns (bytes4(0), 2^256 - 159) — SILENT SUCCESS with an astronomically wrong value.
• Beyond the 78th digit any non-'0' byte returns (ParseDecimalOverflow.selector, 0) — an error, though "overflow" mislabels e.g. "a1" + 77×"0".

Both verified by execution against 35496d8.

Triage framing

Documented-unchecked, and every valid digit 1-9 beyond position 78 genuinely does overflow, so the error path is defensible for digits. Surfaced because silent success is the most dangerous failure shape if any caller ever skips the bounding step, and the position-dependence means fuzzing one region tells you nothing about the other. Possible cheap mitigations if wanted: debug-only assert on digit range, or a doc upgrade spelling out the silent-success consequence.

🤖 Generated with Claude Code