certify: the maps fit control asserts the L refusal by name, and the cap check gets its control

[gafferongames]

The event

Main at dc6ce20 is red on certification: every make test leg fails at tables-maps-fit-negative-control with NEGATIVE CONTROL FAILED: the fit sabotage patched nothing.

The cause

PR #562 rewrote TableMapWireExtent in internal/codegen/cpptable/maps.go. The L bound line now assigns its reason ({ reason = count_over_length; return false; }), and an int32 cap test (if ( n > (uint64_t) INT32_MAX ) { reason = count_over_extent_cap; return false; }) sits before it. The fit control's sed pattern still named the old line, so the sabotage patched nothing and the macro's own guard fired.

Repointing the pattern was not enough. The map gate had no row asserting count_over_length by name. The control had relied on a side effect: the reader row's hostile count of 0xFFFFFFFF, with the L check disabled, produced a measure of about 86 GB that tripped measured_calloc's 256 MiB ceiling. That count sits past INT32_MAX, so the new cap test refuses it before the L check is reached, and the gate stayed green under the sabotage.

The same certification found two more map controls whose patterns #562 moved out from under them: textorder named an f->map_at( slot, i ) call the JSON walk no longer makes (it indexes the entry array in place now), and unreached named TableMapUnreachedEmpty, which extent.go's TableExtentUnreachedEmpty replaced for a map and a list alike.

The fix

• test/tables/maps_main.cpp gains test_measure_refusals in the list gate's shape: a synthetic Fleet wire whose ships map count is 100000 against a short body answers LoadMeasure == -1 with count_over_length, a count of 0x80000000 answers count_over_extent_cap, and a clean wire measures and loads. schema_test_maps measure-refusals prints one summary line, wired into make test as tables-maps-measure-refusals beside the list one.
• tables-maps-fit-negative-control targets the new L line, keeping its shape and its failure message.
• tables-maps-cap-negative-control is new beside it: the INT32_MAX line sabotaged the same way, red when the 0x80000000 row answers count_over_length instead of count_over_extent_cap.
• tables-maps-text-order-negative-control and tables-maps-unreached-negative-control point at the emitted lines as they stand (the unreached one patches extent.go).
• The reader row's comment says what that row now tests (the cap, from the framing alone).

Every other map and list control pattern was checked against its source file (maps.go, lists.go, extent.go, pointers.go, json.go) and matches.

The output

maps: all checks passed (docs/SPEC-TABLES.md §2.8)
map measure refusals: two -1s with their reasons, one clean measure, no counter moved (docs/SPEC-TABLES.md §2.8, §6.5)
negative control: sort turns the MAP GATE red — 24 failures
negative control: dead turns the MAP GATE red — 6 failures
negative control: ascending turns the MAP GATE red — 4 failures
negative control: duplicate turns the MAP GATE red — 2 failures
negative control: keykind turns the MAP GATE red — 3 failures
negative control: clamp turns the MAP GATE red — 2 failures
negative control: fit turns the MAP GATE red — 2 failures
negative control: cap turns the MAP GATE red — 1 failures
negative control: depth turns the MAP GATE red — 33 failures
negative control: textorder turns the MAP GATE red — 1 failures
negative control: unreached turns the MAP GATE red — 2 failures

The fit control's red, from build/map-fit.log:

FAIL test/tables/maps_main.cpp:857: FleetLoadMeasure( w.bytes, w.size, NULL, &reason ) = 11600088, want -1
FAIL test/tables/maps_main.cpp:858: reason == count_over_length

The cap control's red, from build/map-cap.log:

FAIL test/tables/maps_main.cpp:851: reason == count_over_extent_cap

🤖 Generated with Claude Code