make -C v4 post79 does not reproduce POST: the table is stale (LOAD.rest_of_line) and POST79.md records v3 addresses #190

New Issue

2026-11-13T01:42:26Z

rajames commented

2026-11-13 01:42:26 +00:00

Found

make -C v4 post79 (v4/tools/mkpost.py) does not reproduce what is committed (2026-11-12, while adding HEAT-OP's tests, #189). With nothing changed, it rewrites v4/system/post_cases.c (612 lines) and docs/v4.0.0/POST79.md. Two causes:

The table is stale. It was written on 2026-10-07 (4bdb210a); v3 has changed since. Regenerated, it holds one more case, LOAD.rest_of_line (v3 now gets through it in one session), so POST would be 539 cases, not 538; the other ~610 lines of the diff are the case arrays renumbered after it. And SCR.after_load: v3 now prints 1 after 1 LOAD, where POST79.md says it printed nothing. The same with the committed lfs/amd64/starforth (2026-10-01) and with a v3 built from today's source (build/amd64/standard/starforth).
POST79.md is not deterministic. It records what v3 printed, and for >IN.initial, FIND.existing and FIND.user_word that is an address, different on every run (two runs, the same binary: 1076337952 then 241286432). post_cases.c itself is the same run to run.

So POST cannot be changed by regenerating it -- HEAT-OP has no POST case for this reason -- and POST79.md, which says it is written by the tool, can never be checked against it.

Done when

Two runs of make -C v4 post79 on the same tree write the same post_cases.c and POST79.md
post79 uses a v3 built from the tree's source, not a copy that can be older
The table regenerated and committed; POST passes on the three architectures, the stick and test-32; v4/system/POST_FLOOR raised to the new count (#173)

🤖 Filed with Claude Code -- Captain Bob, 2026-11-13: "Create the issues then fix them before the long acceptance test runs"

### Found `make -C v4 post79` (`v4/tools/mkpost.py`) does not reproduce what is committed (2026-11-12, while adding HEAT-OP's tests, #189). With nothing changed, it rewrites `v4/system/post_cases.c` (612 lines) and `docs/v4.0.0/POST79.md`. Two causes: 1. **The table is stale.** It was written on 2026-10-07 (4bdb210a); v3 has changed since. Regenerated, it holds one more case, **`LOAD.rest_of_line`** (v3 now gets through it in one session), so POST would be 539 cases, not 538; the other ~610 lines of the diff are the case arrays renumbered after it. And `SCR.after_load`: v3 now prints `1` after `1 LOAD`, where `POST79.md` says it printed nothing. The same with the committed `lfs/amd64/starforth` (2026-10-01) and with a v3 built from today's source (`build/amd64/standard/starforth`). 2. **`POST79.md` is not deterministic.** It records what v3 printed, and for `>IN.initial`, `FIND.existing` and `FIND.user_word` that is an address, different on every run (two runs, the same binary: `1076337952` then `241286432`). `post_cases.c` itself is the same run to run. So POST cannot be changed by regenerating it -- HEAT-OP has no POST case for this reason -- and `POST79.md`, which says it is written by the tool, can never be checked against it. ### Done when - [ ] Two runs of `make -C v4 post79` on the same tree write the same `post_cases.c` and `POST79.md` - [ ] `post79` uses a v3 built from the tree's source, not a copy that can be older - [ ] The table regenerated and committed; POST passes on the three architectures, the stick and test-32; `v4/system/POST_FLOOR` raised to the new count (#173) 🤖 Filed with [Claude Code](https://claude.com/claude-code) -- Captain Bob, 2026-11-13: "Create the issues then fix them before the long acceptance test runs"

rajames added this to the v4.0.0-alpha.5: SDK milestone 2026-11-13 01:42:27 +00:00

rajames added the

area/v4 labels 2026-11-13 01:42:27 +00:00

rajames referenced this issue from a commit

2026-11-13 03:49:20 +00:00

fix(v4): #190 POST regenerates the same; #16 sanitizers and hosted-check nightly

rajames referenced this issue from a commit

2026-11-13 03:49:21 +00:00