__bridge_transfer and performSelector:withObject:

Question

I have a CFDictionaryRef that doesn't retain/release its objects. When I add an item in it, I take care of retaining it, and later :

NSMutableArray *array = (__bridge_transfer NSMutableArray *)CFDictionaryGetValue(...)
[self performSelector:someSelector withObject:array];

Where someSelector is a variable holding a selector I know about. Now, that second line makes Xcode tell the notorious warning:

PerformSelector may cause a leak because its selector is unknown

Does that mean I should worry about ARC not knowing how to manage memory for the array variable of which I just transferred ownership?

"PerformSelector may cause a leak because its selector is unknown" is a known warning if you compile `[self performSelector:@selector(someSelector) ...]` with ARC - you will find a lot of questions and answers with explanations and workarounds to suppress the warning. I am quite sure that the problem is unrelated to using `__bridge_transfer`. — Martin R, May 30 '13 at 15:25
Yeah, I've seen most of these questions and I use workarounds to suppress this warning whenever possible. My question is that, since this warning appears only when compiling with ARC, citing possible memory leaks, and since `__bridge_transfer`'s use is to give ARC the responsibility of managing memory for this object, are the two anyhow related? — matehat, May 30 '13 at 15:31
I strongly assume that this is unrelated. If I remember correctly, the "possible leak" was the *return value* of the selector, not the arguments. — Martin R, May 30 '13 at 15:36
I just wonder: That warning should not occur with `@selector(doSomethingWithArray:)`, only with an "unknown selector" like `NSSelectorFromString(@"doSomethingWithArray:")`. - So is that your actual code? — Martin R, May 30 '13 at 18:09
You're right that it's not exactly how it's done in code. In fact, `performSelector` is called in a method that receives a selector as an argument. Don't worry, it's not a public method :) I'll edit the post to make it explicit. — matehat, May 30 '13 at 18:19

score 0 · Accepted Answer · edited May 23 '17 at 12:18

From a comment to the accepted answer of this question, it appears that somebody at Apple has confirmed this hypothesis (citing the answer itself):

In fact, there are times when memory management is tied to the name of the method by a specific convention. Specifically, I am thinking of convenience constructors versus make methods; the former return by convention an autoreleased object; the latter a retained object. The convention is based on the names of the selector, so if the compiler does not know the selector, then it cannot enforce the proper memory management rule.

Thus, it has nothing to do with a possible leak of arguments passed to the performSelector: call, but rather to its returned value, for which Objective-C has no way of knowing if it was autoreleased or not. This is also what Martin R from the comments was assuming.

__bridge_transfer and performSelector:withObject:

1 Answers1