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.
62 lines
2.6 KiB
Plaintext
62 lines
2.6 KiB
Plaintext
;;;; (slice-from-ptr p n) — NEXT.md, "a pointer from C needs a length before it
|
|
;;;; can be indexed". The motivating pointers come from C, but nothing about
|
|
;;;; the form does: a (Ptr T) is a (Ptr T) whoever made it, so this case makes
|
|
;;;; its own with (addr (at a 0)) and needs no library and no window.
|
|
;;;;
|
|
;;;; What is asserted, line by line:
|
|
;;;;
|
|
;;;; - the length is the one the caller stated, and (len s) answers it;
|
|
;;;; - the elements read through are the same storage, not a copy — the last
|
|
;;;; two lines write through the slice and read the array back, which is
|
|
;;;; the whole ptr+len claim;
|
|
;;;; - a shorter promise than the truth is legal and is what indexing then
|
|
;;;; believes, because the caller's number is the only length there is;
|
|
;;;; - the result is an ordinary [T]: it slices, it is passed to a function
|
|
;;;; that takes a slice, and the prelude's algorithms work on it.
|
|
;;;;
|
|
;;;; What is NOT here, and is in test_flan.ml's refusal table instead: a
|
|
;;;; negative literal length, a first argument that is not a pointer, and
|
|
;;;; (free (slice-from-ptr ...)) — a slice owns nothing, so free refuses it by
|
|
;;;; the rule it already had.
|
|
|
|
(defvar a [5 i32])
|
|
|
|
(defn total [s [i32]] i32
|
|
(let [acc 0]
|
|
(dotimes [i (len s)]
|
|
(set acc (+ acc (at s i))))
|
|
acc))
|
|
|
|
(defn main [] ()
|
|
(dotimes [i 5]
|
|
(set (at a i) (* (+ i 1) 10)))
|
|
|
|
;; The whole array, as the caller promises it: five elements behind the
|
|
;; address of the first.
|
|
(let [s (slice-from-ptr (addr (at a 0)) 5)]
|
|
(println (len s)) ; 5
|
|
(println (at s 0)) ; 10
|
|
(println (at s 4)) ; 50
|
|
(println (total s)) ; 150
|
|
;; An ordinary [i32] from here on: slice it, and the sub-view still points
|
|
;; into the same storage.
|
|
(println (total (slice s 1 3)))) ; 50
|
|
|
|
;; A promise shorter than the truth. Nothing complains — there is nothing to
|
|
;; complain with — and the length the caller gave is the length indexing and
|
|
;; the bounds check both use.
|
|
(let [s (slice-from-ptr (addr (at a 1)) 2)]
|
|
(println (len s)) ; 2
|
|
(println (total s))) ; 50
|
|
|
|
;; Zero is a length like any other. An empty slice is not a null pointer and
|
|
;; is not an error.
|
|
(println (len (slice-from-ptr (addr (at a 0)) 0))) ; 0
|
|
|
|
;; It is a view, not a copy: a write through the slice is a write to the
|
|
;; array, and this is what would fail if the form ever grew a memcpy.
|
|
(let [s (slice-from-ptr (addr (at a 0)) 5)]
|
|
(set (at s 2) 7)
|
|
(println (at a 2)) ; 7
|
|
(println (total s)))) ; 127
|