Re: Bug in CF/NSString's no-copy constructors (was Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful)
Re: Bug in CF/NSString's no-copy constructors (was Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful)
- Subject: Re: Bug in CF/NSString's no-copy constructors (was Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful)
- From: Michael Tsai <email@hidden>
- Date: Wed, 6 Feb 2008 11:46:25 -0500
On Feb 6, 2008, at 10:55 AM, Alastair Houghton wrote:
I'll just add, publicly, that I think this probably is a bug in
CFString that John has found here. That is, I don't see why
CFString's pointer shouldn't be traced by the collector in this
case (it doesn't appear to be; certainly when I try it the backing
buffer is released). The problem also occurs with NSString's -
initWithBytesNoCopy:length:encoding:freeWhenDone: et al.
I don't think this is a bug. The NSString and CFString APIs do not
indicate that they treat the bytes as scanned memory. In fact, when
you pass in kCFAllocatorNull you are telling CFString that you
"assume responsibility for deallocating the buffer." At the end of -
someMethod, you haven't saved a __strong reference to the buffer, so
the collector is allowed to free it.
--Michael
_______________________________________________
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