You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
runtime/binary-data: complete ArrayBuffer/DataView view and prototype semantics (c262) #4033
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/mainbf9802213 with Test262 pinned to 4249661388e5d3f92a85186213da140a6481490f and Node v25.9.0.
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.
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).
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 callableObject.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.
Activity
fix(runtime): ArrayBuffer.prototype resizable / maxByteLength getters (…
proggeramlug commentedon Jun 2, 2026
Shipped a focused ArrayBuffer sub-fix toward this epic in #4045 (v0.5.1091):
new ArrayBuffer(n).resizablenow returnsfalseand.maxByteLengthreturnsn(were bothundefined).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 returnundefined(matching Node, verified).Still open under this epic: the DataView/ArrayBuffer distinct-identity gap —
new DataView(ab)andabshare one backing address in Perry, soObject.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).fix(runtime): Object.prototype.toString brands for typed arrays/Symbo…
fix(runtime): Object.prototype.toString brands for typed arrays/Symbo…
proggeramlug commentedon Jun 2, 2026
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 — plusSymbol/BigIntbrands.Root cause was a split dispatch: the callable
Object.prototype.toString(object_prototype_to_string_thunk) had its own coarse brand logic separate fromjs_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 tojs_object_to_stringso both paths share the full brand table, then adding the typed-array/Symbol/BigInt arms there.