Joseph Ferano
185d162124
`indexed` took an Array or a Slice, so a `(Ptr T)` that came back
from C was readable at element 0 through `deref` and nowhere else.
The length is not missing from the world — for `font.recs` it is in
the struct, one field over — it was missing from the language.
`(slice-from-ptr p n)` is the form that says it. No marker on the
name: `!` here means mutates and `?` means asks, and `zeroed`, the
nearest neighbour, carries neither; `ptr` is the marker, because a
`(Ptr T)` only ever arrives from a `declare-c`.
Nothing new in the representation. A slice is already {ptr, i64} in
both backends, so this is two insertvalues; `x86.ml` takes the new
constructor on its existing `unsupported` arm.
It refuses a first argument that is not a pointer, a negative literal
length at check time, and a negative computed one at run time — that
last through `signal_block` and `@flan_slice_error`, reused rather
than growing the runtime a function, and *signed*, because
`check_slice` compares unsigned and a negative i32 sign-extends to a
huge u64 that walks through it. Behind `f.md.checks` like the other
two: on at -O0 and -O2, off only when checks were asked off.
It owns nothing and needed no analysis to say so — a slice is not
move-only and carries no allocator, so `free` refuses it by the rule
that already refuses `(as-slice v)`.
`rl/font-recs` and `rl/font-glyphs` are where the promise is written,
beside raylib's own invariant rather than at every call site, and
they are the shape a count-naming binding directive could never have
covered. `examples/text-rectangle-bounds.flan` is the port that
motivated this and it runs; `test/programs/slice-from-ptr.flan`
covers the form with no raylib and no window.
38 lines
1.9 KiB
Plaintext
38 lines
1.9 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 one runs off the end and is not asserted on.
|
|
;;;;
|
|
;;;; 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 (at args 1))))
|
|
s (bytes "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))
|