tables: a clamp answers within its bound, and the text runtime takes the wire's own length

[gafferongames]

Certification's test (ubuntu-latest) job has been red on every main commit since 28133b4 (#592, merged 2026-09-06 06:51Z). af66617, the commit before it, was green. Every merge since has landed on that red. This PR is the fix.

The red is make tables-wire-fuzz-length-negative-control, which removes r.room( len ) from a copy of the C++ emitter and requires the wire fuzzer to go red because the leg died on the mutant. On Ubuntu it went red for another reason, and the leg's heap was corrupted:

NEGATIVE CONTROL FAILED: the wire fuzzer went red, but not on the length check
harness: FAILED after 629 mutants: the report differs: the leg says 0,1,0,1,0,true,read, the oracle says 0,0,0,0,0,true,read
make[1]: *** [Makefile:3459: tables-wire-fuzz-length-negative-control] Error 1
  corpus seed root_full (tabledemo.RootConfig), pass length #10, run seed 24845619678, mutant of 580 bytes
  leg:    loaded=true report=0,1,0,1,0,true,read measure=-1 saved=refused
  oracle: report=0,0,0,0,0,true,read encoded=10 bytes
munmap_chunk(): invalid pointer

The cause

Mutant 629 spells the string field's L as 0xFFFFFFFFFFFFFFFF. #592 added two text helpers that take that length as a signed count:

if ( !TableUtf8Valid( r.buffer + r.offset, (int64_t) len ) ) { ... }
uint64_t keep = len;
if ( keep > 32 ) { keep = (uint64_t) TableUtf8Clamp( r.buffer + r.offset, (int64_t) len, 32 ); r.report->clamped++; }
memcpy( value.name, r.buffer + r.offset, (size_t) keep );

(int64_t) 0xFFFFFFFFFFFFFFFF is -1, and TableUtf8Clamp opens with if ( length <= bound ) { return length; }. -1 is under every bound, so the clamp hands back -1, the caller widens it to SIZE_MAX, and the field's memcpy runs at SIZE_MAX. Replaying that exact mutant against a sanitized build of the sabotaged leg:

==11650==ERROR: AddressSanitizer: negative-size-param: (size=-1)
    #0 <deduplicated_symbol>
    #1 __asan_memcpy
    #2 tabledemo::RootConfigLoadVerdict(tabledemo::RootConfig&, unsigned char const*, long long, tabledemo::TableReport*) TablesTable.h:6084
    #3 Fixed<tabledemo::RootConfig, ...>::run<...>(unsigned char const*, long long, Reply&) wire_fuzz_main.cpp:110
    #4 main wire_fuzz_main.cpp:408

0x61600000038d is located 13 bytes inside of 580-byte region [0x616000000380,0x6160000005c4)
allocated by thread T0 here:
    #0 malloc
    #1 main wire_fuzz_main.cpp:402

TablesTable.h:6084 is the string field's memcpy, and the region is the mutant's own wire buffer.

Why macOS stayed green. On this Air the plain sabotaged leg faults inside that copy, dies on mutant 629, and the control gets the red it names. On glibc/x86-64 the same copy does not fault: it writes outside the destination, corrupts the neighbouring chunk's header, and returns. The leg then writes a full report for mutant 629 (kind_mismatch=1, clamped=1, what a reader that walked off its buffer counts), the harness sees a report difference instead of a death, and the process aborts later in free with munmap_chunk(): invalid pointer. One wrapped size, a loud death on one allocator and a silent out-of-bounds write on the other. The macOS green was the bug crashing conveniently.

The ordinary wire fuzz stays green either way, because r.room( len ) bounds len before the helpers ever see it. That is exactly what the negative control exists to prove, and it stopped being provable.

The fix

A length is a 64-bit number (SPEC-TABLES.md §3), so the text runtime takes it as one. TableUtf8Valid and TableUtf8Clamp now take uint64_t length, and the clamp's answer is never above its bound:

inline int64_t TableUtf8Clamp( const uint8_t * bytes, uint64_t length, int64_t bound )
{
    if ( length <= (uint64_t) bound ) { return (int64_t) length; }
    ...
}

The two call sites that narrowed a wire length, the string field read in codecs.go and the string map key in maps.go, drop their (int64_t) casts. The sites that pass a reader's own span (arms.go, pointers.go, json.go) are non-negative by construction and are unchanged. Goldens are regenerated. The Go oracle's textBoundary takes a slice and cannot express the defect, so it is unchanged.

Nothing changes in a clean build: room( len ) already bounded every length these helpers see.

The red-first test

test_text_clamp_is_bounded in test/tables/main.cpp runs the field read's own three lines over the length the fuzzer's length pass plants and asserts that the size reaching memcpy is within the bound. On the clean tree, with the fix reverted and the test kept:

FAIL test/tables/main.cpp:960: keep <= 32
tables test: 1 failure(s)

It runs in both schema_test_tables and schema_test_tables_asan.

The control's named reason

With the clamp answering within its bound, no leg dies on mutant 629 on any platform, so the control's old name no longer describes what the sabotage does. It never did on Ubuntu, and on macOS it only held because the wrapped memcpy faulted. The second commit renames it to what the missing fit check now produces:

harness: FAILED after 629 mutants: the report differs: the leg says 0,1,0,0,0,true,read, the oracle says 0,0,0,0,0,true,read
negative control: removing the length check from the emitter turns the wire fuzzer RED

Without room( len ) the leg believes a forged L: it takes the payload over bytes the mutant never carried and steps its cursor by a length the body never had, so the fields after it decode out of bytes that are not their own and it reports a kind mismatch the oracle does not. That read is in bounds and deterministic, so the control now goes red the same way on every allocator, where the death it replaces depended on which libc ran it.

Verification

make tables-wire-fuzz-length-negative-control N=0 passes on macOS, and make test is green. Note that certify.yml runs only on pushes to main, so test (ubuntu-latest) is not among this PR's checks.