WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
175974
CacheQueryOptions::isolatedCopy() copies the cache name twice
https://bugs.webkit.org/show_bug.cgi?id=175974
Summary
CacheQueryOptions::isolatedCopy() copies the cache name twice
Daniel Bates
Reported
2017-08-24 19:01:15 PDT
CacheQueryOptions::isolatedCopy() copies the cache name twice.
Attachments
Patch
(2.38 KB, patch)
2017-08-24 19:03 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch
(2.55 KB, patch)
2017-08-24 19:50 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2017-08-24 19:03:49 PDT
Created
attachment 319054
[details]
Patch
Daniel Bates
Comment 2
2017-08-24 19:06:52 PDT
I do not understand how we can came to the decision to have a user-defined constructor for CacheQueryOptions that makes an isolated copy of the passed string. I mean it seems weird that the constructor would charge for an isolated copy when a caller may not pass CacheQueryOptions to another thread. Or is the design that CacheQueryOptions is always passed to another thread?
youenn fablet
Comment 3
2017-08-24 19:21:41 PDT
Comment on
attachment 319054
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=319054&action=review
> Source/WebCore/Modules/cache/CacheQueryOptions.h:-47 > - , cacheName(cacheName.isolatedCopy())
Wouh, that is a strange constructor! This constructor might be needed for some platforms since CacheQueryOptions is initializing some variables. If this patch compiles on win, this patch is fine. Otherwise, the constructor should be kept and take a String&&. r=me, waiting for win bot
youenn fablet
Comment 4
2017-08-24 19:22:57 PDT
(In reply to Daniel Bates from
comment #2
)
> I do not understand how we can came to the decision to have a user-defined > constructor for CacheQueryOptions that makes an isolated copy of the passed > string. I mean it seems weird that the constructor would charge for an > isolated copy when a caller may not pass CacheQueryOptions to another > thread. Or is the design that CacheQueryOptions is always passed to another > thread?
It is definitely a mistake.
Daniel Bates
Comment 5
2017-08-24 19:50:09 PDT
Created
attachment 319061
[details]
Patch
Daniel Bates
Comment 6
2017-08-29 11:09:14 PDT
Committed
r221306
: <
http://trac.webkit.org/changeset/221306
>
Radar WebKit Bug Importer
Comment 7
2017-08-29 11:09:58 PDT
<
rdar://problem/34136830
>
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