WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
184232
Typed array constructor behaves differently when length is not passed or when undefined is passed
https://bugs.webkit.org/show_bug.cgi?id=184232
Summary
Typed array constructor behaves differently when length is not passed or when...
Koby
Reported
2018-04-02 05:28:56 PDT
Hi I've noticed that when I create a typed array, the resulting array's byteLength is different if I'm not passing a length, or if I'm passing an undefined length: const buffer = new ArrayBuffer(8); const view1 = new Uint8Array(buffer); // byteLength == 8 const view2 = new Uint8Array(buffer, undefined, undefined); // byteLength == 0 Tested with the JSC shell from my WebKit fork, forked on github on February, and with Safari on iOS 11.2.6. According to to the ecma standard (
https://www.ecma-international.org/ecma-262/6.0/#sec-%typedarray%-buffer-byteoffset-length
) I think they should produce typed arrays with the same byteLength. I've verified it with Firefox nightly and Chrome nightly (both on Windows), both producing a Uint8Array with the same byteLength(8). Going through JSC's source, I think the issue is in constructGenericTypedArrayView in runtime/JSGenericTypedArrayViewConstructorInlines.h. It handles undefined byteLength for DataViews, but not the "length" for other typed arrays. Thanks, Koby
Attachments
Patch
(2.47 KB, patch)
2020-06-12 17:00 PDT
,
James Darpinian
no flags
Details
Formatted Diff
Diff
add test
(3.07 KB, patch)
2020-06-19 17:58 PDT
,
James Darpinian
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2018-04-03 10:32:01 PDT
<
rdar://problem/39145280
>
Koby
Comment 2
2018-04-03 23:58:05 PDT
Also, if you think that my suggested fix in constructGenericTypedArrayView is OK, I'll be happy to send a patch.
James Darpinian
Comment 3
2020-06-12 16:48:12 PDT
Thanks for the investigation, I think you are right about the fix. This is causing some WebGL conformance tests to fail so I will make a patch.
James Darpinian
Comment 4
2020-06-12 17:00:03 PDT
Created
attachment 401806
[details]
Patch
Yusuke Suzuki
Comment 5
2020-06-12 17:34:16 PDT
Comment on
attachment 401806
[details]
Patch Nice, can you add a test in `JSTests/stress/`?
Yusuke Suzuki
Comment 6
2020-06-12 17:36:01 PDT
And let's wait for EWS results. If it affects on WebGL conformance tests, it is possible that these tests in LayoutTests start showing "PASS" or something. In that case, this patch needs to update -expect files too.
Yusuke Suzuki
Comment 7
2020-06-12 17:52:44 PDT
Seems that it is not used in LayoutTests for now. So, adding a test to JSTests/stress/ and that's all :)
Yusuke Suzuki
Comment 8
2020-06-12 18:14:14 PDT
Comment on
attachment 401806
[details]
Patch The patch looks good. Can you add a test to JSTests/stress?
James Darpinian
Comment 9
2020-06-19 17:58:38 PDT
Created
attachment 402364
[details]
add test
Yusuke Suzuki
Comment 10
2020-06-19 18:16:03 PDT
Comment on
attachment 402364
[details]
add test r=me
EWS
Comment 11
2020-06-19 21:06:42 PDT
Committed
r263315
: <
https://trac.webkit.org/changeset/263315
> All reviewed patches have been landed. Closing bug and clearing flags on
attachment 402364
[details]
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug