Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suggested changes #1

Merged
merged 17 commits into from
Jul 28, 2023
Merged

suggested changes #1

merged 17 commits into from
Jul 28, 2023

Conversation

jmdyck
Copy link

@jmdyck jmdyck commented Jul 28, 2023

see commit messages

jmdyck added 17 commits July 28, 2023 16:14
because it denotes a String value
This one is debatable.
I mostly did it for my convenience,
but I think PR tc39#2877 also preferred some similar expansions.
Because the result of IntegerIndexedObjectLength
is `a non-negative integer of ~out-of-bounds~`,
you need to deal with the `~out-of-bounds~` possibility
before doing any arithmetic on it.

Here, I've simply asserted that the result isn't `~out-of-bounds~`,
but I don't know that that's true.
You might have to do something different (e.g., throw).
RawBytesToNumeric returns a Number or a BigInt
(in this case a BigInt),
so convert that to a mathematical value
for comparisons/arithmetic with a math value.
`_iieoRecord_` is `an Integer-Indexed Object With Buffer Witness Record`,
which doesn't have `[[ViewedArrayBuffer]]` field.
`_O_` is a TypedArray,
but IsFixedLengthArrayBuffer requires a [Shared]ArrayBuffer.
Its algorithm has a couple '?',
so add 'throw completion' to its return type.
... because `_newLength_` could be any ES language value,
but `_O_.[[ArrayBufferByteLength]]` requires a non-neg integer.
@syg
Copy link
Owner

syg commented Jul 28, 2023

This all looks great, thanks for the many fixes!

@syg syg merged commit 6a3c859 into syg:rab-stage4 Jul 28, 2023
1 check failed
@jmdyck
Copy link
Author

jmdyck commented Jul 28, 2023

So all the not ~out-of-bounds~ assertions were valid?

@syg
Copy link
Owner

syg commented Jul 29, 2023

So all the not out-of-bounds assertions were valid?

I skimmed them and looked like it? They were all right after a ValidateTypedArray without any intervening user code, and ValidateTypedArray would've thrown for out-of-bounds.

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.

2 participants