RESOLVED FIXED Bug 103851
createRareData should return a PassOwnPtr
https://bugs.webkit.org/show_bug.cgi?id=103851
Summary createRareData should return a PassOwnPtr
Elliott Sprehn
Reported 2012-12-02 21:24:44 PST
Don't use an OwnPtr for Node rare data
Attachments
Patch (3.64 KB, patch)
2012-12-02 21:30 PST, Elliott Sprehn
no flags
Patch (3.67 KB, patch)
2012-12-02 21:34 PST, Elliott Sprehn
no flags
Patch (3.11 KB, patch)
2012-12-03 10:48 PST, Elliott Sprehn
no flags
Patch for landing (3.07 KB, patch)
2012-12-03 11:31 PST, Elliott Sprehn
no flags
Elliott Sprehn
Comment 1 2012-12-02 21:30:49 PST
Elliott Sprehn
Comment 2 2012-12-02 21:34:53 PST
Eric Seidel (no email)
Comment 3 2012-12-02 22:20:30 PST
Comment on attachment 177175 [details] Patch This should have been PassOwnPtr anyway, right? I think it's good to use PassOwnPtr here, even if we always call leakPtr.
Elliott Sprehn
Comment 4 2012-12-02 23:12:46 PST
(In reply to comment #3) > (From update of attachment 177175 [details]) > This should have been PassOwnPtr anyway, right? I think it's good to use PassOwnPtr here, even if we always call leakPtr. I guess if we want to wrap it then it should be PassOwnPtr though I'm not sure there's an advantage of using PassOwnPtr vs OwnPtr. What's the reason for wanting to wrap it?
Eric Seidel (no email)
Comment 5 2012-12-02 23:20:00 PST
(In reply to comment #4) > (In reply to comment #3) > > (From update of attachment 177175 [details] [details]) > > This should have been PassOwnPtr anyway, right? I think it's good to use PassOwnPtr here, even if we always call leakPtr. > > I guess if we want to wrap it then it should be PassOwnPtr though I'm not sure there's an advantage of using PassOwnPtr vs OwnPtr. > > What's the reason for wanting to wrap it? The goal of wrapping it is the same as any use of smartpointers. :) To make the ownership clear and prevent memory leaks. it just so happens that every caller calls leakPtr() today, but this being OwnPtr/PassOwnPtr prevents any future leaks.
Darin Adler
Comment 6 2012-12-03 10:00:26 PST
Comment on attachment 177175 [details] Patch This change doesn’t seem good. Using a return type of PassOwnPtr is an excellent way to make it clear to people reading the code what the lifetime of a returned object is, even if we use leakPtr right after the fact. Moving to a raw pointer does not seem like an improvement, unless there is some concrete benefit of doing so. Using a return type of OwnPtr is incorrect, though, and should be fixed.
Elliott Sprehn
Comment 7 2012-12-03 10:48:37 PST
Elliott Sprehn
Comment 8 2012-12-03 10:51:14 PST
(In reply to comment #6) > (From update of attachment 177175 [details]) > This change doesn’t seem good. Using a return type of PassOwnPtr is an excellent way to make it clear to people reading the code what the lifetime of a returned object is, even if we use leakPtr right after the fact. Moving to a raw pointer does not seem like an improvement, unless there is some concrete benefit of doing so. > > Using a return type of OwnPtr is incorrect, though, and should be fixed. Okay, patch uploaded with these changes.
Eric Seidel (no email)
Comment 9 2012-12-03 11:02:44 PST
Comment on attachment 177285 [details] Patch I don't see why you're adding the ASSERT. That method, as written, doesn't need to care about whether it has rare data or not yet. setRareData might care, but this method seems idempotent as previously written.
Eric Seidel (no email)
Comment 10 2012-12-03 11:03:53 PST
Comment on attachment 177285 [details] Patch Please consider removing the ASSERT.
Elliott Sprehn
Comment 11 2012-12-03 11:13:34 PST
(In reply to comment #10) > (From update of attachment 177285 [details]) > Please consider removing the ASSERT. Okay I'll remove the assert.
Elliott Sprehn
Comment 12 2012-12-03 11:31:49 PST
Created attachment 177294 [details] Patch for landing
Dirk Pranke
Comment 13 2012-12-04 14:43:11 PST
Comment on attachment 177294 [details] Patch for landing Clearing flags on attachment: 177294 Committed r136573: <http://trac.webkit.org/changeset/136573>
Dirk Pranke
Comment 14 2012-12-04 14:43:14 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.