Re: Bug in CF/NSString's no-copy constructors

FROM : Michael Tsai
DATE : Wed Feb 06 19:29:58 2008

On Feb 6, 2008, at 12:46 PM, Alastair Houghton wrote:

>> 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


Sorry, that's what I meant.

> 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.


The string was allocated using kCFAllocatorDefault, but the 
deallocator was specified as kCFAllocatorNull. The docs say:

"If the buffer does not need to be deallocated, or if you want to 
assume responsibility for deallocating the buffer (and not have the 
CFString object deallocate it), pass kCFAllocatorNull."

If CFString is not going to be responsible for deallocating the 
buffer, then it would not make sense to rely on CFString keeping the 
buffer alive for you.

> 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.


I'm not saying there would be harm; I'm just saying that the API 
doesn't say that it traces the pointer, so it's not a bug if it 
doesn't. In the absence of a general guideline or an explicit 
promise, passing a buffer to a CF call is just like passing it to, 
say, a sqlite3 call.

--Michael