new Uint8Array(n) with non-literal n returns a zero-length buffer

[proggeramlug]

Repro

function make(n: number) {
  const u = new Uint8Array(n);
  console.log('n=' + n + ' length=' + u.length);
}
make(100);
make(1024);

Expected

n=100 length=100
n=1024 length=1024

Actual (Perry 0.5.30)

n=100 length=0
n=1024 length=0

Likely cause

In crates/perry-codegen/src/expr.rs, Expr::Uint8ArrayNew has fast paths for the literal cases Expr::Integer(n) and Expr::Number(n) (routed to js_buffer_alloc), but the catch-all Some(e) => … arm falls through to js_uint8array_from_array, which treats the number as an ArrayHeader* pointer and silently yields a zero-length buffer.

Workaround

Buffer.alloc(n) works with computed/variable sizes. new Uint8Array(<literal>) works too.

Related

The pair for writes (u8[i] = v being a silent no-op) was a similar codegen stub in Expr::Uint8ArraySet; fixed separately.

[proggeramlug]

Fixed in v0.5.31.

Root cause: in crates/perry-codegen/src/expr.rs (Expr::Uint8ArrayNew), the Some(e) catch-all arm called js_uint8array_from_array(arr_handle) unconditionally. For a numeric n, unbox_to_i64 AND'd the NaN-box bits with POINTER_MASK_I64 — which for a finite double strips the upper 16 bits and yields an effectively null pointer — and js_uint8array_from_array then read length = 0 from the fake ArrayHeader.

Fix: new runtime dispatch js_uint8array_new(val: f64) that inspects the NaN-box tag — POINTER_TAG (0x7FFD) routes to js_uint8array_from_array, plain IEEE double routes to js_uint8array_alloc(val as i32), anything else (undefined/null/bool/string/bigint) returns an empty buffer. The catch-all codegen arm now calls this helper with the raw NaN-boxed f64 instead of an unboxed "pointer". Literal-integer / literal-number fast paths to js_buffer_alloc are unchanged.

Verified against the repro — make(100) → length=100, make(1024) → length=1024.