Files
solvecraft/docs
jyviko e7e613b6fb Records: the item budget bounds input, not the kernel's own results (Refs #3992)
The portable record's 4,000,000-item budget refused a real result: the join of a level-4
Menger sponge's level-3 sponges ended with "SMLib export: the mapped B-rep does not validate:
portable B-rep: item budget". The budget guards records from outside the kernel, and a body
the kernel built in memory from inputs already bounded where they came in isn't hostile.

Brep::validate keeps the budget for records read from outside: native design caches
(decode_native_body, behind its own 256 MiB, 1M-per-array and 20M-value caps) and STEP import.
The new Brep::validate_built runs every other check, without the cap, on what the kernel
builds: SMLib's export of an operation's result, a body's record (Body::from_record, after
the decoder has checked a file's), a part of a validated record, the record handed back to
SMLib, and the validity check. Its checks are linear in a record already in memory.

SMLib's export bounded its counts by the same budget; a count is now bounded by SMLib's own
longest array (flat::MAX_LEN, checked on entry), which keeps every offset worked out from
the counts from overflowing, and the redundant topology-length cap goes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-29 22:15:38 -04:00
..