65db360b913ac1cb8cb7316b4fe0d33db8c84d32
Nine sites used hardcoded byte counts sized for str=16. With str's in-memory size invariant about to grow under #1, the next-pointer or field write would land past the slot and corrupt the next bump allocation — selfhost/CLAUDE.md flags this exact pattern. Over-alloc by 8B is harmless under the bump allocator, so bumping the constants is correct at str=16 too. Sites: fnret, enumtype, modent (×4), ffi, strlit, enummember slot sizes; loopendbuf, loopcontbuf, yieldbuf LOOP_MAX strides. Latent bug found by str-size-hang-debug worker via PC trace on a str=24 probe: fnretlookup spun forever because the frnext write fell into the string heap, forming a cycle. Fix verified at str=16 (130/130 + 994/995) and probed at str=24 (994 still green; further graduation work tracked by #1).
Description
No description provided
Languages
C
89.4%
Python
7.2%
Makefile
2.3%
Shell
0.8%
Assembly
0.3%