Joseph Ferano
d6fc15474b
The author: "I think I prefer length over len, because then I'll use len as the variable name". One arm in check.ml, one row in the table beside it, and every (len x) in lib, test, examples, vendor, spike, docs, web, emacs, plan.org and NEXT.md rewritten. Shadowing and builtin/ had already taken most of the sting out: a (defn len ...) was legal and won in its own file, and builtin/len reached past it. What was left is that len was still a builtin — the defn earned a warning, and a wrapper had to say builtin/ at every inner call. Now there is nothing under the short name: len is an ordinary identifier in every position, which is what (let [len (length xs)] ...) wants. length takes over as shadowing's worked example rather than the feature losing one. shadow-builtin.flan, builtin-qualified.flan, pkgs/shadowed and the builtin/ rows in test_flan move to it and go on testing shadowing. A call to a len nothing defines is answered where an unknown function is, after every table and after the shadowing guard, so a program with its own len never reaches it. The sentence is said rather than guessed at — len and length are three edits apart and the did-you-mean's net is one — and the call is written back out through spell_arg, as-slice's spelling lifted out of it and now shared, so what is printed compiles. sand.flan:33 still calls the old name and is the author's to change; until it does, test_acceptance and test_session abort there. Both were run green against a copy with that one line changed. FIX.org says so.
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 (length (slice-from-ptr (addr (at arr 0)) n)))
|
|
|
|
:else (println "?"))
|
|
0))
|