fix(as370): restore the -Werror build on modern GNU gcc, and add CI to keep it

[mgrossmann]

Closes #11
Closes #33

The two build breaks

Both diagnostics broke the project's documented build line on current GNU gcc while Apple clang saw neither — so "warning-clean under -Werror" only ever held on one toolchain, and a contributor on gcc could not build at all.

-Wdangling-pointer (#11). expr_val() parked its cursor argument in the file-static xp_, and callers pass stack buffers, so on return xp_ pointed at storage that had gone out of scope. Nothing outside the expression evaluator reads xp_ — its only uses are lines 228..283 — so this was latent rather than live, but the store is genuinely invalid and gcc is right to reject it. The cursor is now cleared before returning, with the early-return path folded into the same exit so there is one place to do it.

-Wformat-overflow (#33). The deck sequence number went through a format string built at run time, sprintf(fmt, "%%0%dld", nd), which gcc cannot bound. The width now comes from the argument instead — snprintf(d, sizeof d, "%0*ld", nd, ...) — same output, no constructed format, and fmt[] disappears entirely.

Verification

Built with gcc 16.1 at -O2 -Wall -Wextra -Werror, which is stricter than the CI runner: it reports #11, and as it happens does not reproduce #33 (gcc's range propagation has moved on). #33 is fixed on the merits — the construct the warning is about is gone — rather than against a reproduction, and that is worth stating plainly.

Output is unchanged where it matters:

• make test-as370 → ALL SAMPLES BYTE-IDENTICAL TO IFOX00
• the libc370 corpus check produces output identical byte-for-byte before and after the commit (checked by stashing, re-running, and diffing the logs — 74 CHANGED + 7 drift both times)

On that: test-corpus is currently red, and was already red before this branch. Its committed SHA manifest has drifted from libc370's current sources (7 modules assemble that the manifest does not list). Nothing here touches that, but it means the regression gate is not gating anything at the moment — worth its own issue.

The CI

cc370 had none, while mbt's reusable workflow builds this repo's main for every downstream project. So a broken main went out to the whole ecosystem and came back as a red build in mvsmf — the signal travelling in exactly the wrong direction.

.github/workflows/build.yml builds the five standalone tools and runs the as370, ld370 and xmit370 suites. Scope is deliberately the tools and not the GCC fork: that is where the regressions have been, and make compiler takes minutes.

Both gcc and clang build the tools, on purpose. The -Wformat-overflow break that prompted all this reached main because Apple clang does not implement that warning — a clang-only check cannot defend -Werror.

libc370 is cloned as a sibling because four as370 samples assemble against its macro libraries; nothing is built from it. test-corpus stays out (red for the reason above) and so does test-cc370 (needs the GCC fork).

Dry-run in the exact layout the workflow creates, all four steps green, including the skip paths for xmit370's two external fixtures.

One thing found on the way

61b4e99 was titled "complete the crent370 → libc370 rename in test harness + docs" but left the shell variable itself called CRENT in tests/run.sh and tests/listref/check.sh, while the Makefile and tests/corpus/check.sh had already moved to LIBC370 — two names for one thing, the stale one naming a libc that is frozen and no longer checked out. Renamed to LIBC370 throughout; default unchanged, and all three paths (default, override, bad path) verified.

https://claude.ai/code/session_018SbqQkXrAyDhVgcF8X8cdz