Normalize zero-size data out pointers on the create side (createArrayBuffer/createBuffer/createBufferCopy)

Open

#62 opened on Jul 23, 2026 0 comments 0 reactions 1 assignee View on GitHub

@nazarhussain is already working on this.

Since Jul 28, 2026.

Assessment

This issue has not been assessed yet.

Description

Type: Bug

Context

Noted while reviewing #56. That PR normalizes the get side (napi_get_arraybuffer_info etc.) so a zero-length result with a NULL/arbitrary data pointer can no longer produce a Zig slice that violates the non-null pointer invariant.

The create side has the same class of issue: Env.createArrayBuffer, Env.createBuffer, and Env.createBufferCopy take out: ?*[*]u8, and TypedArray.from/alloc pass a non-nullable buf_ptr into them. For size == 0, Node-API may write NULL into that non-nullable [*]u8, after which from does @ptrCast(@alignCast(buf_ptr)).

float64Scale(new Float64Array(0), 2.5) (added in #56's tests) exercises this path and currently passes — but only because address 0 happens to satisfy every alignment check. It is the same type-invariant violation, accidentally safe rather than correct.

Proposal

Apply the same nullable-pointer normalization as #56: receive the out pointer as ?*anyopaque (or make the out param nullable-aware), and have TypedArray.from/alloc short-circuit to an empty/zero-length result for len == 0 before any alignment cast.

Refs: src/Env.zig (createArrayBuffer/createBuffer/createBufferCopy), src/js/typed_arrays.zig (from, alloc)

Dominant language: Zig
Stars: 4
Forks: 4
PR merge metrics: No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.