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.
46 lines
2.4 KiB
Plaintext
46 lines
2.4 KiB
Plaintext
;;;; Bounds checks, NEXT.md item 2. One program, one case per argument, so a
|
|
;;;; trap is observable: the checked build exits 134 with the source location
|
|
;;;; on stderr.
|
|
;;;;
|
|
;;;; The unchecked build is not uniform, and the split is the point. An index
|
|
;;;; past the end runs off the end there and is not asserted on — that is what
|
|
;;;; --no-bounds-checks buys. Two of the cases below still trap: the reversed
|
|
;;;; range at n = 2 and the negative promise at n = -2, because neither is a
|
|
;;;; bounds check. Both are the claim that a slice's length word is a count,
|
|
;;;; and a build that drops them does not produce an unchecked slice, it
|
|
;;;; produces a value that is not one. See check_slice in lib/emit.ml.
|
|
;;;;
|
|
;;;; The selector is also the index wherever it can be, which is what keeps the
|
|
;;;; index dynamic — a literal would let the checker reject it outright one day
|
|
;;;; (that is a separate job) and lets LLVM fold the branch away here.
|
|
(defvar arr [3 i32])
|
|
|
|
(defn main [args [string]] i32
|
|
(let [n (i32 (bytes->i64 (bytes-view (at args 1))))
|
|
s (bytes-view "hello")] ; len 5
|
|
(cond
|
|
;; In bounds, including both edges: the last index, and a slice that
|
|
;; ends exactly at len. Neither may trap.
|
|
(= n 0) (do (print (at arr 2))
|
|
(print (slice s 1 5))
|
|
(print (slice s 5 5)) ; empty at len is legal
|
|
(println ""))
|
|
|
|
(= n 3) (print (at arr n)) ; past the end of a fixed array
|
|
(= n -1) (print (at arr n)) ; negative index
|
|
(= n 9) (print (at s n)) ; past the end of a slice
|
|
;; The write path lowers through place/Pindex rather than through At, so
|
|
;; it is checked separately even though the message is the same.
|
|
(= n 7) (set (at arr n) 1) ; write past the end
|
|
(= n 4) (print (slice s n 9)) ; hi past the end
|
|
(= n 2) (print (slice s n 1)) ; reversed range
|
|
;; (slice-from-ptr p n) has nothing to check n against — the caller's
|
|
;; number is the only length there is — so what it checks is that the
|
|
;; number is not absurd. Signed, deliberately: the comparisons the other
|
|
;; two checks use are unsigned, and a negative i32 sign-extended to i64
|
|
;; is a huge unsigned value that sails straight through them.
|
|
(= n -2) (print (len (slice-from-ptr (addr (at arr 0)) n)))
|
|
|
|
:else (println "?"))
|
|
0))
|