On Aug 18, 2011, at 1:15, Bill Cheeseman wrote: On Aug 17, 2011, at 5:22 PM, Ken Thomases wrote: On Aug 17, 2011, at 4:06 PM, Rick Mann wrote:
I have a method named createFoo, from which I return an object with a retain count of 1. The Xc4 static analyzer is complaining about a potential leak, but I thought it would notice the "create" in the name...
"Create" in a name is a Core Foundation convention, not a Cocoa convention. This is specifically called out in the Memory Management Programming Guide <http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html>:
Despite the fact that we all know the "create rule" is a Core Foundation naming convention, I have found that the Xcode 4 Analyzer depends on the presence of "create" or "copy" in a Cocoa method signature that returns a Core Foundation object to get memory management reporting right.
Here's how I figured it out. I have a framework that uses Cocoa methods to return Core Foundation objects. The leaks tool and the leaks instrument reported memory management problems in an application using my framework -- leaks. When I ran the Analyzer on it, it reported memory management issues that made no sense to me. I decided to try adding "create" and "copy" to method names that returned CFRetained Core Foundation objects, then ran the Analyzer again. This time it reported different memory management issues, and they made perfect sense to me. When I fixed the problems, the Analyzer no longer reported issues. To prove the point, I then ran the leaks tool and used Instruments to run its leaks instrument, and all my leaks were gone. QED.
So I think it is important to follow the "create rule" when naming Cocoa methods that return Core Foundation objects. This isn't documented, so I would certainly appreciate feedback from Apple engineers.
Sounds more like you discovered a bug (or more than one) in the analyzer. For sure, the analyzer does not properly recognize ownership when CF and Cocoa gets mixed. For instance when a Cocoa method (without any of the keywords) returns a CFRetain'ed object, the analyzer does not see a problem. In fact, even if I use retain on a CF object instead of CFRetain, it sees no problem. So the conclusion is that you cannot rely on the analyzer in Xcode 4.x when CF and Cocoa are mixed. Therefore your observation is also something that you cannot rely on to be reported correctly. So you must follow the documentation, and this says that what you say is wrong: Cocoa methods starting with "create" should NOT return retained objects, neither Cocoa nor CF objects. It really is about Cocoa method naming rules (one set of rules) against Core function naming rules (another set of rules), it's NOT about return types (except for non-object return types of course).
Christiaan
|