On Wed, Jun 3, 2009 at 12:41 AM, Ken Thomases <k...@codeweavers.com> wrote: > On Jun 2, 2009, at 9:21 PM, Michael Ash wrote: > >> The NSString methods are unlikely to be problematic here. NSData is >> troublesome because it's returning an internal pointer. In other >> words, it's a pointer to some memory that it already holds on to in >> the normal course of things, and it gives you that pointer. Since it >> manages this memory explicitly, its lifetime is linked to the lifetime >> of the NSData object. >> >> The NSString case is quite different. It's (probably?) not an internal >> pointer at all. Instead, it's newly allocated memory being returned to >> you. The NSString (probably?) does not hold a pointer to this memory, >> and thus its lifetime is not linked to the lifetime of the NSString >> object that it came from. When you ask an NSString for its UTF8String, >> it (probably?) has to create that from scratch by converting its >> internal storage, unlike NSData which just returns its internal >> storage directly. >> >> I put all of those "probably" things up there because it is at least >> conceivable to have an NSString where this *is* an internal pointer, >> so you might not want to count on this being true. However I'd judge >> it to be pretty unlikely. Wouldn't hurt to make your code safe against >> it even so. > > I'm not so sure about "unlikely" and "probably", as opposed to merely > "possibly". The thing is, it might very well be internal to some object, > even if that object is not the string specifically. > > In the non-GC case, the most likely way for NSString to return a C string > that has a lifetime of the autorelease context is for NSString to create an > autoreleased NSData to hold the properly encoded bytes, and then return the > -bytes of that data object. Even if that's not the exact way NSString does > it, in the non-GC case there's really no way to implement an "autoreleased > buffer" that doesn't involve an interior pointer of something. Something > has to manage the lifetime of that buffer, after all, and it's probably an > object in the autorelease pool. > > Apple may have changed the implementation as it implemented GC, so that > NSString allocates the data buffer from the collector, but it may have just > left the implementation alone. The non-GC approach still works in a GC > environment, except for the interior pointer issue.
Apple would have to have different implementations for the GC and non-GC case here. If the pointer isn't interior to the NSString then it *can't* be interior to some other object, because you'd have no way to keep the thing alive. The NSString is the only thing that the caller is guaranteed to hold a strong reference to, so it's the only thing you could reasonable base the lifetime of the storage on. The RR method of creating an NSData and returning its interior pointer simply won't work in the GC world, so they would need different code no matter what. There is no solution to this problem which works in both worlds. The good news is that it's pretty easy to write code that allocates memory from an autoreleased NSMutableData in RR and which uses NSAllocateCollectable in GC. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
