Joseph Ferano
2e203f64b8
The INSERTIONSORT crash, all three rulings (FIX.org 2026-09-20): - (bytes s) allocates a writable copy through the allocator surface — context or (bytes s a), StorageExhausted with retry, a registry note in dev builds (flan_bytes_dup, lowered like vec-new). (bytes-view s) is the old zero-cost reinterpret, renamed, read-only by convention; every in-repo reader swept over to it. (string b) unchanged. - String constants were already read-only on both backends at -O0; now pinned — bytes-copy.flan rows on LLVM/-O0/--x86, and dies_segv rows asserting the write-through-view trap on both backends. - A dev build installs a SIGSEGV/SIGBUS handler by the same dev-only constructor slot that arms the registry: one line naming the address and the innermost frame, then the trap-hook park — stopped, not dead, the daemon serving. No agent: message and re-raise. Release builds untouched. Pinned by trap_park over dev-segv.flan.
20 lines
944 B
Plaintext
20 lines
944 B
Plaintext
;;;; A store through (bytes-view "literal") lands in the string constant's
|
|
;;;; own storage, which both backends emit read-only — LLVM as a `constant`
|
|
;;;; global, x86 in .rodata — so the write traps where it happens instead of
|
|
;;;; corrupting the literal. Pinned at -O0 on both backends, where the store
|
|
;;;; is really emitted; at -O2 LLVM deletes it as undefined behaviour, which
|
|
;;;; is why this program has no -O2 row. The trap itself (SIGSEGV on a
|
|
;;;; read-only page) is the defined consequence of the emission, not a bet on
|
|
;;;; anything further.
|
|
;;;;
|
|
;;;; If this ever exits 0, string data has become writable somewhere and the
|
|
;;;; read-only-by-convention story of bytes-view is silently gone.
|
|
|
|
(defn main [] i32
|
|
(let [v (bytes-view "INSERTIONSORT")]
|
|
(set (at v 0) \Z)
|
|
;; Never reached: the store above traps. Printing anyway makes a failure
|
|
;; loud — output where none was expected.
|
|
(print (string v))
|
|
0))
|