Bug 175974

Summary:

CacheQueryOptions::isolatedCopy() copies the cache name twice

Product:

WebKit

Reporter:

Daniel Bates <dbates>

Component:

WebCore Misc.

Assignee:

Daniel Bates <dbates>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

cdumez, webkit-bug-importer, youennf

Priority:

Keywords:

InRadar

Version:

WebKit Local Build

Hardware:

All

OS:

All

Attachments:

Description	Flags
Patch	none
Patch	none

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.