From 6240537103107d37eee28c2b068c9290af818c9c Mon Sep 17 00:00:00 2001 From: Simon Dick Date: Sat, 10 Oct 2026 06:42:34 +0100 Subject: [PATCH] changelog: backfill #117 and #118 entries for 0.9 Both merged to main in the window between branching the 0.9 release PR (#119) and it landing, so the version-bump commit went in without them. Also notes --sanitize's new exit-99 override in the CLI Reference's exit-codes summary, which #118 made inaccurate (a sanitize violation is no longer only ever "the guest never got to run at all"). Co-authored-by: Claude Sonnet 5 --- userdocs/CLI-Reference.md | 5 +++++ userdocs/Changelog.md | 21 +++++++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/userdocs/CLI-Reference.md b/userdocs/CLI-Reference.md index 240de1b..d368d47 100644 --- a/userdocs/CLI-Reference.md +++ b/userdocs/CLI-Reference.md @@ -49,6 +49,11 @@ overflow, an invalid instruction). In every one of those cases volamos prints a diagnostic to stderr naming exactly what went wrong before exiting. `--help` and `--version` exit `0`. +The one case where a normal run's own exit code is overridden: under +[`--sanitize`](#-sanitize), a run that reported any violation exits +`99` instead of the guest's own code, so a harness that only checks +the exit status doesn't pass a run that corrupted memory. + ## `-v`, `--verbose` Logs every emulated library call to stderr as it happens — library diff --git a/userdocs/Changelog.md b/userdocs/Changelog.md index b2d3344..e58e14e 100644 --- a/userdocs/Changelog.md +++ b/userdocs/Changelog.md @@ -5,6 +5,27 @@ version scheme in `Cargo.toml`. ## 0.9 +- **`--sanitize` exits `99` on a violation, and no longer misreports a + `longjmp` return as a stack-smash** (issue #118). A `longjmp` returns + through its `setjmp` slot, which a later call's frame may still + occupy if nothing unwound it first — the check now recognizes a + return landing on a reused slot instead of reporting it. Separately, + a run that logged any violation now exits with status `99` instead + of the guest's own exit code, so a harness that only checks the exit + status doesn't pass a run that corrupted memory; a program started + with `System()`/`Execute()` from inside the run still returns its + own code to its caller. + +- **The current task is now a real CLI process, and a bare `System()` + command is looked up in `C:`** (issue #117). The task previously had + `pr_CIS`/`pr_COS`/`pr_ConsoleTask` all zero, so startup code reading + them directly instead of calling `Input()`/`Output()` — DICE's does — + ran with no stdin, stdout or stderr; `SelectInput`/`SelectOutput` now + keep those fields in step. Separately, a `System()`/`Execute()` + command with no volume was resolved only against the current + directory, but the real shell also searches `C:` — SAS/C's `sc` + invokes its linker as `slink WITH ...` and failed on exactly this. + - **Dispatch now recognizes task-struct corruption instead of misreporting it as stack bounds.** `check_stack_bounds` reads `tc_SPLower`/`tc_SPUpper` fresh from guest memory on every dispatched