Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upPrevent setting observable effects to [[ArrayLength]] #874
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anba
Apr 7, 2017
Contributor
For TypedArray#fill we should move the [[ArrayLength]] access to run before ToNumber(value)
Will be fixed in #866 (ae46560).
ValidateAtomicAccess is the other case in the specs we can verify [[ArrayLength]] being accessed after an observable step where we do not check for a detached buffer.
See #870 (comment).
Will be fixed in #866 (ae46560).
See #870 (comment). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
That's it, thanks! |
leobalter commentedApr 6, 2017
While reviewing #870, I've got a question on whether we should define accessing [[ArrayLength]] right after an observable step.
For
TypedArray#fillwe should move the[[ArrayLength]]access to run beforeToNumber(value)The suggestion above allows a implementation to define what is done to [[ArrayLength]] if gets a detached buffer.
See that
TypedArray#lengthreturns0if it has a detached buffer:ValidateAtomicAccess is the other case in the specs we can verify
[[ArrayLength]]being accessed after an observable step where we do not check for a detached buffer.This one is tricky. Because
typedArraymay already be detached before the observableToIndexoperation.My suggestion is to access the
lengthproperty for this case, while ValidateAtomicAccess is not a direct TypedArray operation and it can't protect it.This way we have may minimize the chances for weird effects: