On Apr 23, 2014, at 10:52 PM, Nico Weber <[email protected]> wrote:

> On Wed, Apr 23, 2014 at 10:39 PM, Chandler Carruth <[email protected]> 
> wrote:
> 
> On Wed, Apr 23, 2014 at 10:16 PM, Nico Weber <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 
> 
> _______________________________________________
> cfe-commits mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to