Re: Clarification on MMM rules for init?
Re: Clarification on MMM rules for init?
- Subject: Re: Clarification on MMM rules for init?
- From: Ken Thomases <email@hidden>
- Date: Sat, 21 Jan 2017 11:05:24 -0600
On Jan 21, 2017, at 10:43 AM, Dave <email@hidden> wrote:
>
> I’m looking at some old code and have found what I think is a long standing bug. This is a class that has an initWithXXX method which may fail, in this case it calls [self autorelease] and returns nil. However, I have found a case whereby does a [self autorelease], but instead of retuning nil, it returns self. Is this an error?
Yes, it's an error. Init methods are assumed to release one reference to the receiver and return a +1 reference on whatever they return. If the method returns the original object (the same value of self as at the entry to the method), then this has no cumulative effect, but it matters if the method returns a different object (or nil).
In any case, the caller expects to receive a +1 reference (if not nil). The broken method you describe is not following these rules.
> If so, this framework is being called from an ARC based App, what would be the effect of this error on the App?
ARC is just doing automatically what manual-retain-release (MRR) code should do. The caller of an init method should act as though it received a +1 reference. That is, it does not need to do an additional retain to keep a strong reference. When that strong reference is cleared, it must do a release.
ARC will not do a retain on the object even if it keeps a reference. Since the init method you describe is broken, the object will be under-retained and could be deallocated while there's still a reference to it. That will eventually cause problems such as messaging a deallocated object, messaging an unrelated object that happens to have reused the memory location of the original, or crashing by treating non-object memory as an object. Also, ARC will eventually release the object when it clears the reference it has (just as MRR code should), which has all of the same dangers.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden