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
This is because instep 7-9 of https://tc39.es/ecma262/#sec-json.parse we always get the completion value without actually checking if it's a normal completion or a throw completion.
This is not actually observable in the implementations I could try, since all of them don't allow creating strings that long.
The text was updated successfully, but these errors were encountered:
Note that if a spec algorithm says to (e.g.) "throw a SyntaxError", that's just a shorthand for returning a particular throw completion. (See 5.2.3.2 Throw an Exception.) There's no semantic difference between returning a throw completion via 'return' (or '?') vs returning it via 'throw'.
Hm. It seems like step 2 is meant to ensure that step 7's completion is normal. But ECMA-404 doesn't limit the length of an array structure, so your example isn't caught there.
And step 6 asserts that the ParseText in step 4 has no errors. But ArrayLiteral doesn't have an EarlyError if it contains (recursively) too many elements, so again your example passes through.
So yeah, it seems like JSON.parse needs to better handle the possibility that step 7's completion is abrupt.
Given a variable
let input = "[" + "0,".repeat(2**32 - 1) + "0]"
, this code:is defined to return a RangeError (for the invalid array length, as defined in steps 3-5 of https://tc39.es/ecma262/#sec-arraysetlength), rather than throw it.
This is because instep 7-9 of https://tc39.es/ecma262/#sec-json.parse we always get the completion value without actually checking if it's a normal completion or a throw completion.
This is not actually observable in the implementations I could try, since all of them don't allow creating strings that long.
The text was updated successfully, but these errors were encountered: