r207076 - Fix two leaks found by LSan.

[Argyrios Kyrtzidis]

On Apr 23, 2014, at 10:52 PM, Nico Weber <thakis at chromium.org> wrote:

> On Wed, Apr 23, 2014 at 10:39 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> On Wed, Apr 23, 2014 at 10:16 PM, Nico Weber <nicolasweber at gmx.de> wrote:
> +        if (DidSetDeprecatedMessage)
> +          clang_disposeString(*deprecated_message);
>          *deprecated_message = cxstring::createDup(Deprecated->getMessage());
> +        DidSetDeprecatedMessage = true;
> 
> Can we really not tell that the message doesn't hold a string to dispose of? Maybe even better, have clang_disposeString just no-op in that case (the way free, delete, etc do)?
> 
> *deprecated_message is user-controlled, and there's no public api to construct an empty CXString as far as I know.
> 
> A different approach would be to
> 
>   if (deprecated_message)
>     *deprecated_message = cxstring::createNull();
> 
> at the beginning of the function, then it's possible to unconditionally call clang_disposeString() – but it'd be a behavior change, since the function would then set *deprecated_message to an empty string (instead of not modifying it). I don't know how strict libclang is about behavior changes

getCursorPlatformAvailabilityForDecl() is called by clang_getCursorPlatformAvailability which initializes the values with cxstring::createEmpty(). This creates an empty string which is a no-op to call dispose on.
I simplified a bit with r207081.

BTW, thanks for fixing the leaks!

> .
>  
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140423/66ad2f4b/attachment.html>