On May 12, 2012, at 2:31 PM, Quincey Morris wrote: > On May 12, 2012, at 10:17 , Ken Thomases wrote: > >> That's not necessarily so. And/or requesting the mutableBytes may do the >> equivalent of retain+autorelease on the NSMutableData. >> >> Consider an inexact analog. The -[NSString UTF8String] method seems to >> create an autoreleased NSData (or similar object) to hold the UTF-8-encoded >> C string that it returns. It's not returning the NSData object, obviously, >> it's just using the autoreleased lifetime to manage the lifetime of the C >> string. > > I think the difference is that for UTF8String, there is an API contract that > promises the result will be an object (and it has the lifetime behavior of > any returned object that is returned with +0 retain semantics, as the > documentation warns). > > For mutableBytes, there's no API contract that it's an object at all, or that > it has any particular lifetime semantics if it is.
Well, you're the one who asserted something very concrete about when the interior pointer was deallocated. You were claiming that Andreas couldn't have seen what he said he saw. My point is that in the absence of a contract you can't be sure. > If it was an object of some kind in Andrea's testing, that should be regarded > as luck. Right, but Andreas wasn't looking to take advantage of the extended lifetime. The extended lifetime was a problem for him. He was asking if it made sense that he needed to use an autorelease pool to ensure the data's lifetime was *not* extended. You asserted that it could not make sense. I asserted that it might. Regards, Ken _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
