Bug 162267 – [GTK] Clean up DataObjectGtk handling

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Garcia Campos]

In some cases the ownership of DataObjectGtk instances is not clear enough, and we have hacks to avoid memory leaks because of that.

[Carlos Garcia Campos]

Created attachment 289342 [details]
Patch

[WebKit Commit Bot]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Michael Catanzaro]

Comment on attachment 289342 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=289342&action=review

> Source/WebCore/platform/gtk/PasteboardHelper.cpp:295
> +        TemporaryChange<DataObjectGtk*> change(settingClipboardDataObject, const_cast<DataObjectGtk*>(&dataObject));

Why is this function receiving a const DataObjectGtk*? Why were you unable to get rid of this const_cast?

> Source/WebKit2/Shared/gtk/PasteboardContent.cpp:36
> +PasteboardContent::PasteboardContent(const WebCore::DataObjectGtk& data)
> +    : dataObject(const_cast<WebCore::DataObjectGtk&>(data))

Again, why is the parameter const? What call site cannot be fixed?

[Carlos Garcia Campos]

(In reply to comment #3)
> Comment on attachment 289342 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=289342&action=review
> 
> > Source/WebCore/platform/gtk/PasteboardHelper.cpp:295
> > +        TemporaryChange<DataObjectGtk*> change(settingClipboardDataObject, const_cast<DataObjectGtk*>(&dataObject));
> 
> Why is this function receiving a const DataObjectGtk*? Why were you unable
> to get rid of this const_cast?
> 
> > Source/WebKit2/Shared/gtk/PasteboardContent.cpp:36
> > +PasteboardContent::PasteboardContent(const WebCore::DataObjectGtk& data)
> > +    : dataObject(const_cast<WebCore::DataObjectGtk&>(data))
> 
> Again, why is the parameter const? What call site cannot be fixed?

Both are special cases. You can't create smart pointers from const references/pointers, but in these particular cases the object is going to be const, the only change we are going to do to the object is taking a reference, and RefCounted::ref() is const indeed. So we can't fix the callers, because it's correct to receive consts, but we cast to allow creating a Ref<> that we know we are ot going to modify.

[Carlos Garcia Campos]

Committed r206197: <http://trac.webkit.org/changeset/206197>