Since PassOwnPtr was introduced, we can switch all the code using auto_ptr to using OwnPtr / PassOwnPtr. Patch forthcoming.
Created attachment 49079 [details] Proposed fix: change signatures, remove <memory> and auto_ptr reference
Comment on attachment 49079 [details] Proposed fix: change signatures, remove <memory> and auto_ptr reference LGTM. My only concern is if "Type" could end up getting used for a stack object. We only use PassOwnPtr to return or pass values, never as a stack object or an instance variable. 05 template<> struct CrossThreadCopierBase<false, false, ResourceRequest> { 115 typedef std::auto_ptr<CrossThreadResourceRequestData> Type; 106 typedef PassOwnPtr<CrossThreadResourceRequestData> Type; 116107 static Type copy(const ResourceRequest&); 117108 }; 118109 119110 template<> struct CrossThreadCopierBase<false, false, ResourceResponse> { 120 typedef std::auto_ptr<CrossThreadResourceResponseData> Type; 111 typedef PassOwnPtr<CrossThreadResourceResponseData> Type; 121112 static Type copy(const ResourceResponse&); 122113 };
(In reply to comment #2) > (From update of attachment 49079 [details]) > LGTM. > > My only concern is if "Type" could end up getting used for a stack object. We > only use PassOwnPtr to return or pass values, never as a stack object or an > instance variable. [snip] Looking at the auto_ptr and PassOwnPtr implementation, there is no constructor for stack allocated object. The constructor takes a pointer type: template <typename T> class PassOwnPtr { typedef typename RemovePointer<T>::Type ValueType; typedef ValueType* PtrType; PassOwnPtr(PtrType ptr = 0) : m_ptr(ptr) { } } So unless I miss something, using a stack object will be detected at compile time. Thanks for the review!
Landed the patch in r55066. Follow-up change in bug 35221 (for JavaScriptCore).