Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#62 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

@nazarhussain 已经在做这个了。

开始于 2026年7月28日。

评估

这个 Issue 还没有评估数据。

描述

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)

主要语言
Zig
星标
4
派生
4
PR 合并指标
30 天内没有已合并 PR

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

ChainSafe/zapi 的其他 Issue

查看 ChainSafe/zapi 的全部 Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。