Re: Why should we set ivars to nil in dealloc?
Re: Why should we set ivars to nil in dealloc?
- Subject: Re: Why should we set ivars to nil in dealloc?
- From: j o a r <email@hidden>
- Date: Sun, 13 Apr 2008 14:53:57 -0700
On Apr 13, 2008, at 1:08 PM, Ferhat Ayaz wrote:
Maybe it is possible to invoke dealloc twice in multithreaded
applications? And setting to nil prevents an exception like
BAD_ACCESS if this happens?
I'm not sure how you would end up in that type of situation (the
default implementation of retain/release is thread safe), but lets for
arguments sake say that you do - This would still indicate that you
have a serious threading problem in your application, one that you
should not attempt to hide by assigning nil to your ivars in dealloc.
On Apr 13, 2008, at 12:56 PM, stephen joseph butler wrote:
Well, in C/C++ accessing a NULL pointer will throw an error. But
that type
of error is much safer than the alternates: double free or accessing
a freed
region. Those aren't just programming problems, but security concerns.
Now, messaging nil in Obj-C is a pretty common thing; whether it's
intentional or not. But I think the security issues are still there
with
double free or messaging a dealloced object.
If you want to protect yourself against that, while still allowing for
clear and early detection of programmer errors, how about re-assigning
the ivars to something that could never be an object address - Like 0x1.
j o a r
_______________________________________________
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