Skip to content

[4.x] Reject a maxByteLength the CLR cannot allocate when the ArrayBuffer is built (backport of #4458) - #4468

Open
michaelthyregod wants to merge 1 commit into
sebastienros:4.xfrom
michaelthyregod:backport/4.x-arraybuffer-max-byte-length
Open

michaelthyregod wants to merge 1 commit into
sebastienros:4.xfrom
michaelthyregod:backport/4.x-arraybuffer-max-byte-length

Conversation

@michaelthyregod

Copy link
Copy Markdown
Contributor

Backport of #4458, the follow-up to #4441 (and to its 4.x backport #4463).

On 4.17.0 and 4.x, new ArrayBuffer(0, { maxByteLength: 2 ** 31 - 1 }) builds a resizable buffer whose limit can never be reached; the RangeError only comes at the first resize that asks for it. The JsArrayBuffer constructor now compares against ClrLimits.MaxArrayLength instead of int.MaxValue (AllocateArrayBuffer step 9.a), so the 56 values from 2,147,483,592 to 2 ** 31 - 1 are a RangeError at construction, with V8's message Invalid array buffer max length. The cherry-pick applied cleanly; the new tests in ArrayBufferAllocationLimitTests are converted from NUnit to xUnit.

Verified locally: Jint.Tests 7994 passed / 4 skipped (net10.0) and 7909 / 4 (net472); Jint.Tests.PublicInterface 1967 passed / 9 skipped (net10.0) and 1959 / 9 (net472); Jint.Tests.Test262 102513 passed / 171 skipped; 0 failures.

🤖 Generated with Claude Code

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant