using performSelector in a c function to call delegate - objective-c

Question

Scenario
if (delegate && [delegate respondsToSelector:#selector(aboutTextUpdated:)]) {
[delegate aboutTextUpdated:aboutText];
}
to simplify this kind of checks in my project I created a couple of c functions as below and used them.
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
id callSelectorOnDelegateWithObject(SEL selector,NSObject *delegate,id object)
{
if (delegate != nil && [delegate respondsToSelector:selector] == YES)
{
if (object != nil)
{
return [delegate performSelector:selector withObject:object];
}
else
{
return [delegate performSelector:selector];
}
}
return nil;
}
id callSelectorOnDelegate(SEL selector,NSObject *delegate)
{
if (delegate != nil && [delegate respondsToSelector:selector] == YES)
{
return [delegate performSelector:selector];
}
return nil;
}
#pragma clang diagnostic pop
they were called as below
callSelectorOnDelegateWithObject(#selector(aboutTextUpdated:), delegate, aboutText);
Problem
I get EXC_BAD_ACCESS error some times, but not in a reproducible manner. The exception occurred when the c function was called but before executing the first statement. When I replace the function call with actual if statement, then the error never occurs. To meet project deadline I went ahead with that change. But couldn't get this error out of my head.
What is causing the error?
More Background
The project uses ARC, minimum target is iOS 5.0
The project uses AFNetworking 1.* to get data from server, core data to save it in the app and NSNotification for inter app communication
The methods given to perform selector always return void

Answer 1

We would need to see the details of the crash to know more. My best guess is that there are occasional calls to callSelectorOnDelegateWithObject() where object is nil but the method identified by selector actually does take an argument. In that case, you're using just -performSelector:, not -performSelector:withObject:. So, the method receives garbage for its argument.
If some code called callSelectorOnDelegateWithObject() rather than callSelectorOnDelegate() then you should pass the object argument through unconditionally. The caller passing nil does not mean you can drop the argument. The nil probably (or, at least, possibly) is important.
That said, this whole approach doesn't seem like a good idea. I would not find this scheme simpler than the code snippet at the top of your question.
You can simplify that code snippet by not explicitly checking if delegate is non-nil. The -respondsToSelector: check will already return false if delegate is nil, because messaging nil always results in false.
Finally, you should never compare against YES (or TRUE, etc.). You're taking an expression which is already a boolean expression and then making it a compound boolean expression. Let me ask if you would ever write code like the following:
if (([delegate respondsToSelector:selector] == YES) == YES)
...
If you would not write that second == YES (and an infinite sequence of further comparisons to YES), then you should understand why you shouldn't have written the first.
Beyond that, any non-zero value is a true value. YES is only one such value. For any given method which returns a boolean value, you can't be sure that the true value it returns is actually YES as opposed to any other true value.