Re: Static analyzer gives false positive on block passed to C callback - how to silence it?
Re: Static analyzer gives false positive on block passed to C callback - how to silence it?
- Subject: Re: Static analyzer gives false positive on block passed to C callback - how to silence it?
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 18 Oct 2010 04:44:33 -0700
Use Block_copy() and Block_release() instead. They are more appropriate anyway in that you are interfacing with a pure C API.
That will likely silence the analyzer. If not, please file a bug.
b.bum
On Oct 17, 2010, at 23:29, Gwynne Raskind <email@hidden> wrote:
> I have a situation where I'm wrapping blocks support around the callbacks of an external portable C library. The code looks like this:
>
> typedef void (*externalLibCallback)(void *userdata);
> extern void externalLibDoSomethingLater(externalLibCallback func, void *userdata);
>
> static void MyCallback(void *userdata)
> {
> void (^block)(void) = (void (^)(void))userdata;
>
> block();
> [block release];
> }
>
> @implementation MyEventHandlingObject
>
> - (void)eventThatNeedsToCallTheLibrary:(void (^)(void))aCallbackBlock
> {
> externalLibDoSomethingLater(MyCallback, (void *)[aCallbackBlock copy]);
> }
>
> The static analyzer (both Xcode's builtin and the latest release version) throws a warning on the last line, "Potential leak of an object allocated on line N". I know why it warns: it can't see that the copied block is released by the callback. The block does have to be copied without being autoreleased, because the external library does not guarantee the timing of the callback (and even if it did I can't make assumptions about the timing of the autorelease pool). The warning is definitively false; the callback is always called and thus the block is always released. However, none of the analyzer annotation attributes seem able to solve this situation.
>
> Is there a way to silence the warning or redesign the code to avoid it, or do I need to file a request for an attribute((released_later))?
>
> -- Gwynne
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden