On 4 Apr 2014, at 2:22 pm, Varun Chandramohan <varun.chandramo...@wontok.com> wrote:
> @property (assign) NSMutableArray* contents; > [config setContents:(NSMutableArray *)[[NSPropertyListSerialization > > propertyListWithData:plistXML > > options:0 > > format:&format > > error:&errorDesc] retain]]; > Interestingly, the static code analysis find the call of "retain" as a leak. > How do I address this issue? A number of problems here. I've cut/pasted the bits I see. First, by declaring your property as 'assign', you've lost any advantage of synthesizing a memory-management correct setter. If this were retain instead, it would be better, since the m/m of the contents array is then isolated to the setter method. You'd have to override -dealloc of course, and set that property to nil. Second, declaring the property as mutable is questionable - it might be internally mutable, but you usually don't want to expose that to the outside world unless you really mean it. Instead declare it immutable but back it internally with a mutable object - an easy way to do that is to declare the ivar yourself and use the @synthesize directive to associate it with your property, or else write your own -setContents: method that copies the contents of the immutable array parameter to the internal mutable one. On the other hand if your class never adds or subtracts from that array, you could just make it immutable. Thirdly, casting the return value of [NSPropertyListSerialization propertyListWithData...] to NSMutableArray doesn't turn that object into a mutable array - you've just forced the type system to stop helping you. Certainly retaining it here is the wrong thing to do as well, since this code doesn't own that object, and has no business retaining it. That's what the analyser is trying to tell you. Overall, it's easily fixed: if the internal array really is mutable, declare an ivar NSMutableArray and associate it with your contents property, which should either retain or copy, or you write your own setContents: method. Do all the memory management of that ivar insidethe object that owns it (the TempConfig object), adding relevant methods for -init and -dealloc as needed. Don't cast the return type of something - it won't magically turn it into a different object type. Stop trying to memory manage outside the object that owns the managed thing. (A class method of that object doesn't really count). --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
