Number- and unicode-parsing batch (2026-07-07 review): a non-shortest-form UTF-8 acceptance gap, JSON unescape emitting CESU-8 the library itself rejects, and decimal drains that wrap u64 and return OK with a wrong value.
UTF8.c:64 _utf8sDrain32 — 4-byte overlong bound `code_point <
0xffff should be < 0x10000`: overlong U+FFFF (F0 8F BF BF) is accepted. Classic filter-bypass vector. (Distinct from landed ABC-003.)
JSON.c:261-271 JSONUnEscape — no surrogate-pair handling:
😀 becomes two 3-byte CESU-8 sequences that the module's own utf8sValid/_utf8sDrain32 reject as UTFBAD. Any astral char in standard JSON produces output failing the library's own validation.
01.h:394-406 u64decdrain — unchecked a = a*10 + digit;
"18446744073709551617" wraps to 1 and i64decdrain (INT.c:5-22) / utf8sDrainInt (UTF8.c:97-114) return OK with value 1. The I64_MAX range tests only catch wraps that land high. (Feed-side INT64_MIN item is MEM-021; this is the drain-side wrap.)
UTF8.c:74-86 utf8sDrainFloat — truncates the numeral at 31 bytes:wrong value AND cursor stops mid-number, poisoning the next token. The copy-to-NUL-pad + strtod dance is also the abc.mkd anti-pattern.
JSON.c:122-153 formatter — JSONFmt("}") decrements u8 depth 0→255
(lexer accepts a bare "}"), feeding 255 indents; clamp or fail. Also JSON.c:189 sane() omits the indent arg — NULL crashes.
01.h:438 i64Zig — i * 2 is signed-overflow UB for |i| ≥ 2^62,
reachable via ZINTu8sFeedInt (ZINT.h:112). Fix: ((u64)i << 1).
JSON.c:257 — accepts non-JSON escape \0 (asymmetric withJSONEscape); at least comment the leniency.
decimal, 40-char float, "}" format, ZINT-encode of I64_MIN/2^62.
check the decimal accumulator, unbounded float parse (ragel or ryu-side length check), clamp depth, unsigned Zig.
fast path branch-light.