WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
145352
String.prototype.charAt() should use StringView.
https://bugs.webkit.org/show_bug.cgi?id=145352
Summary
String.prototype.charAt() should use StringView.
Andreas Kling
Reported
2015-05-23 14:02:55 PDT
String.prototype.charAt() currently always reifies JSString. This is wasteful if the JSString is a substring. It also uses jsSingleCharacterSubstring() which is a counter-productive optimization, so let's remove that.
Attachments
Patch
(5.51 KB, patch)
2015-05-23 14:11 PDT
,
Andreas Kling
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Andreas Kling
Comment 1
2015-05-23 14:11:09 PDT
Created
attachment 253651
[details]
Patch
WebKit Commit Bot
Comment 2
2015-05-26 11:54:17 PDT
Comment on
attachment 253651
[details]
Patch Clearing flags on attachment: 253651 Committed
r184865
: <
http://trac.webkit.org/changeset/184865
>
WebKit Commit Bot
Comment 3
2015-05-26 11:54:20 PDT
All reviewed patches have been landed. Closing bug.
Geoffrey Garen
Comment 4
2015-12-15 16:17:56 PST
Comment on
attachment 253651
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=253651&action=review
> Source/JavaScriptCore/runtime/StringPrototype.cpp:788 > + StringView string = thisValue.toString(exec)->view(exec);
This code is wrong. It takes a temporary reference to a string's backing store, but nothing prevents that backing store from being deleted or garbage collected. This code is only possible because JSString::SafeView will automatically convert to StringView, due to its operator StringView(). It is very weird that the safe type automatically converts to the unsafe type. That makes the safe type unsafe too.
Darin Adler
Comment 5
2015-12-15 16:35:37 PST
Comment on
attachment 253651
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=253651&action=review
>> Source/JavaScriptCore/runtime/StringPrototype.cpp:788 >> + StringView string = thisValue.toString(exec)->view(exec); > > This code is wrong. It takes a temporary reference to a string's backing store, but nothing prevents that backing store from being deleted or garbage collected. > > This code is only possible because JSString::SafeView will automatically convert to StringView, due to its operator StringView(). It is very weird that the safe type automatically converts to the unsafe type. That makes the safe type unsafe too.
I spotted the same mistake in another patch recently.
Andreas Kling
Comment 6
2015-12-15 16:40:22 PST
crab That operator StringView() is kind of a footgun eh.
Darin Adler
Comment 7
2015-12-15 19:45:06 PST
Oh, all we need to do is to make the return type be SafeView instead of StringView.
Darin Adler
Comment 8
2015-12-15 19:46:03 PST
(In reply to
comment #4
)
> It is very weird > that the safe type automatically converts to the unsafe type. That makes the > safe type unsafe too.
The job of SafeView is to make code like this OK: function(value->view(exec)); It doesn’t make code with local variables safe. Perhaps we can find an even better solution.
Darin Adler
Comment 9
2015-12-15 19:46:26 PST
(In reply to
comment #7
)
> Oh, all we need to do is to make the return type be SafeView instead of > StringView.
local variable type, not return type Never occurred to me to actually use SafeView as a local variable.
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