Joseph Ferano
a4c6b996ff
The trio the author decided on 2026-09-20 is now all built: def is CL's defparameter — its initialiser runs on every daemon re-run, unguarded, so an edited initialiser repaints the same storage on C-c C-c plus re-run — defonce (Clojure's name for CL's defvar, per the author) initialises once behind the .init~once. flag, and defconst stays the image. One parse arm reads both forms; the difference is Ast.reinit, carried to Tast.global's grerun. Emit.startup_plan gives a def no guard flag, and Check.check_global lifts every def initialiser — zero and literal included — into global/<n>, so the host's startup reaches it through the function cell and a re-evaluated def swaps it (Session's def_inits; Emit.redefinition declares the cell for a non-sibling target). The old defvar spelling is refused with the rename and both compiling spellings, and every program, test, doc and editor list is swept — except sand.flan, the author's live WIP, whose seven defvar lines are flagged in FIX.org and keep its three dependent tests red on this branch.
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.
|
|
(defonce 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))
|