On Tue, Jun 2, 2009 at 7:28 PM, Greg Guerin <[email protected]> wrote: > Quincey Morris wrote: > >> For completeness, I just want to add (after a bit of discussion off- list) >> that it remains unclear whether the pointer returned by 'UTF8String' or >> 'fileSystemRepresentation' is to be regarded as an interior pointer or not. >> (My guess is "not".) >> >> So I submitted feedback against the NSString documentation asking for >> clarification of the GC case, and if anyone has any direct knowledge then it >> would be helpful to post a definitive answer to the list. > > > http://lists.apple.com/archives/objc-language/2009/Mar/msg00037.html > > IIRC, the case of UTF8String and/or fileSystemRepresentation came up later > in the thread (it began with the NSData internal-pointer case). I'm too > lazy to look for it, or even google keywords, but I remember it being quite > an interesting discussion.
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. Mike _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
