Re: Bug in CF/NSString's no-copy constructors
Re: Bug in CF/NSString's no-copy constructors
- Subject: Re: Bug in CF/NSString's no-copy constructors
- From: Alastair Houghton <email@hidden>
- Date: Wed, 6 Feb 2008 17:46:09 +0000
On 6 Feb 2008, at 16:46, Michael Tsai wrote:
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.
That's true, but it doesn't matter whether they treat the bytes as
scanned memory or not; that would only change whether putting pointer
data in the bytes was safe. The problem is whether the pointer itself
is being traced, which isn't happening right now; the docs *do* say
(in the Garbage Collection Programming Guide) that NULL,
kCFAllocatorDefault and kCFAllocatorSystemDefault cause objects to be
allocated in the GC zone, so I don't think it's unreasonable to expect
that the pointer will be traced.
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.
It's *an* argument, certainly.
I just think that there's no harm in making the pointer visible to the
collector; it doesn't hurt if the pointer isn't pointing into the GC
pool. And it would mean that you could pass a chunk of memory
allocated using NSAllocateCollectable(), which seems not
unreasonable. I don't think it's hugely important, since you can
always use malloc() and let it call free() (which will happen
automatically), but if it's an easy fix then it's probably worth
doing. Not that many people will do this or indeed should be doing
this kind of thing.
Anyway, at the very least it's worth drawing to the attention of
whoever's responsible for CFString at Apple. If they want to fix it,
great. If not, the docs could be updated to say that you shouldn't
pass GC'd memory into those APIs.
If we could see the sources for CFString, we could probably make a
better determination as to whether this was worth fixing. But
currently the CF project's sources aren't visible (for Leopard) :-(
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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