Patch: Wrong ownership sematics for BSTRs

Hey.

Looking through TSVN code I've noticed the following pattern: CString::AllocSysString() is called and the returned value (raw BSTR) is passed as an "in" parameter to a COM call and not freed later. This makes BSTRs leak - noone takes ownership of the newly created BSTR. The same I guess applies to SafeArrayPutElement() - MSDN (http://msdn.microsoft.com/en-us/library/ms891261.aspx) says "If the data element is a string <skipped> the function copies it correctly." which implies that a new BSTR is created and owned by the array and the BSTR returned by CString::AllocSysString() is leaked.

A patch is proposed - it uses CComBSTR to manage BSTRs lifetime and addresses some other minor issues.

Best wishes.
Dmitry.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2435791

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].