Normalize zero-size data out pointers on the create side (createArrayBuffer/createBuffer/createBufferCopy)
@nazarhussain 已经在做这个了。
开始于 2026年7月28日。
评估
这个 Issue 还没有评估数据。
描述
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
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
ChainSafe/zapi 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 92/100
-
Type: Maintenance
难度 1/5 1 小时以内 新手友好度 76/100
-
clearer errors 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 76/100
-
难度 2/5 1-3 小时 新手友好度 72/100