Skip to content

runtime/binary-data: complete ArrayBuffer/DataView view and prototype semantics (c262) #4033

Closed

Description

@andrewtdiz

User outcome

Binary-heavy packages, Fetch bodies, crypto, encoders, and protocol code should be able to rely on ArrayBuffer/DataView shape, brand checks, and byte access semantics.

Current signal

Tested on current origin/main bf9802213 with Test262 pinned to 4249661388e5d3f92a85186213da140a6481490f and Node v25.9.0.

Command:

scripts/test262_subset.py --root vendor/test262 --dir built-ins/ArrayBuffer built-ins/DataView --max 80 --timeout 8 --sample-cap 20 --report target/test262-reports/arraybuffer-dataview.json

Result: pass=40, runtime-fail=40, parity=50.0%.
Per dir: built-ins/ArrayBuffer pass=27/runtime-fail=30; built-ins/DataView pass=13/runtime-fail=10.

Representative failures:

  • built-ins/ArrayBuffer/allocation-limit.js: huge lengths should throw RangeError.
  • built-ins/ArrayBuffer/isView/arg-is-dataview-subclass-instance.js: ArrayBuffer.isView should recognize DataView subclass instances.
  • built-ins/ArrayBuffer/isView/invoked-as-a-fn.js: static method is missing/not callable through the expected surface.
  • built-ins/ArrayBuffer/prototype/byteLength/*: getter/descriptor/brand checks are incomplete.
  • built-ins/ArrayBuffer/prototype/slice/end-default-if-undefined.js: slice default end behavior is wrong.

Shortest useful fix

Cover the binary object model used by app code before broader SharedArrayBuffer work:

  • Reify ArrayBuffer constructor/prototype static surface, including isView, name, length, and descriptors.
  • Implement/align ArrayBuffer.prototype.byteLength getter brand checks and descriptors.
  • Fix ArrayBuffer.prototype.slice bounds/default behavior for ordinary buffers.
  • Ensure DataView instances and subclasses are recognized by view checks.
  • Add focused c262 regression fixtures for the samples above.

Acceptance

  • Representative Test262 cases above pass.
  • The targeted ArrayBuffer/DataView slice improves materially from the current 50.0% baseline.
  • Existing Buffer, Fetch body, and TypedArray smoke tests continue to pass.

JIT product notes

Core: ordinary ArrayBuffer/DataView semantics used by real packages.
Defer: SharedArrayBuffer, Atomics, resizable/growable buffers, and transfer semantics unless already required by these samples.
Future signal: widen when Fetch/crypto/Buffer package fixtures expose deeper binary edge cases.

Activity

  1. proggeramlug commented on Jun 2, 2026

    @proggeramlug
    Contributor

    Shipped a focused ArrayBuffer sub-fix toward this epic in #4045 (v0.5.1091): new ArrayBuffer(n).resizable now returns false and .maxByteLength returns n (were both undefined).

    Perry has no resizable ArrayBuffers, so a plain ArrayBuffer is always non-resizable and maxByteLength === byteLength. Added both getters to the registered-buffer property path, scoped to a plain ArrayBuffer — DataView/SharedArrayBuffer/typed-array views correctly still return undefined (matching Node, verified).

    Still open under this epic: the DataView/ArrayBuffer distinct-identity gap — new DataView(ab) and ab share one backing address in Perry, so Object.prototype.toString.call(dv) reports [object ArrayBuffer] instead of [object DataView]. That needs DataView to carry its own identity separate from the backing buffer (a deeper reification).

  2. proggeramlug commented on Jun 2, 2026

    @proggeramlug
    Contributor

    Shipped a typed-array brand fix toward this epic in #4061 (v0.5.1097): Object.prototype.toString.call(new Int32Array()) now returns [object Int32Array] (was [object Number]), covering all 12 typed-array kinds — plus Symbol/BigInt brands.

    Root cause was a split dispatch: the callable Object.prototype.toString (object_prototype_to_string_thunk) had its own coarse brand logic separate from js_object_to_string, mis-tagging raw-i64 typed arrays as [object Number] (a small pointer bit pattern reads as a finite f64). Fixed by delegating the thunk to js_object_to_string so both paths share the full brand table, then adding the typed-array/Symbol/BigInt arms there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions