moonbitlang / core / 6509

89%

push

github

fix(builtin): stop nulling vacated Array slots so views cannot read invalid memory

Taking a view from an `Array` shares the underlying buffer, and every
shrinking operation cleared the slots it vacated with `%fixedarray.set_null`.
A view created before such a mutation then read a null slot: SIGSEGV on native
for reference element types, `null` on wasm-gc, `undefined` on JS.
`Array::view` is plain `pub`, so this was undefined behaviour reachable from
entirely safe code.

Vacated slots are now left alone, so a view can only ever observe valid values
of `T`. Mutating an array while a view of it is alive stays a program error,
but what the view yields is merely unspecified rather than invalid.

The cost is that a removal retains what it removes, and that applies uniformly:
`clear` empties an array the same way `pop` shortens it, and neither writes to
the slots it gives up. No existing signature changes. The removed elements are
released once a later push reuses the slot, once the buffer grows, or once the
array is dropped, so clear-and-refill self-heals -- each push releases one old
occupant, and repeated fill/drain cycles on one array hold flat.

Reclaiming on demand is explicit. The new `Array::release_unused(placeholder~)`
overwrites every slot from `length()` to `capacity()` with the placeholder,
which is exactly the region any removal leaves behind: one pass, no
allocation, capacity kept. `shrink_to_fit` was
already releasing those elements by letting the old buffer go, at the cost of
an allocation plus a copy of every survivor; that is now documented rather
than incidental.

Writing into that region needs no high-water mark, because it is always either
NULL or a live reference, never garbage. `%fixedarray.make_uninit` NULL-fills
for reference element types -- it has to, since `moonbit_drop_object` walks a
REF_ARRAY's full capacity and skips slots with `if (!obj) continue` -- and
`moonbit_make_ref_array_with_blit` NULL-fills everything outside the b... (continued)

4 of 4 new or added lines in 1 file covered. (100.0%)

16862 of 18535 relevant lines covered (90.97%)

283389.82 hits per line