On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> The problem here is > that you're expecting one pointer to keep a *different* pointer live, > which the GC does not make any guarantees about. Pre garbage collection, this was straightforward: as long as you retain your NSData, the pointer returned by [thatData bytes] is valid. Post garbage collection, you would expect the rule to be equivalent: as long as you have a strong reference to your NSData, the pointer returned by [thatData bytes] is valid. Until the stack frame is popped, you have a strong reference to your NSData. Unless of course the compiler thinks it knows better. But I agree with Ken: the compiler is wrong. > Basically, under GC, my impression is that it should be considered > invalid to return a pointer to a caller which depends on the lifetime > of the parent object. In this case, for example, NSData really should > be returning a pointer to collected memory, so that instead of having > to pull dirty tricks to keep the NSData pointer alive, you can just > pull regular easy tricks to keep the char * pointer alive. Even if the NSData returned collected memory, it would still be less straightforward to use GC than pre-GC memory management. I thought GC was supposed to make memory management easier?! > The problem with this is that it's incompatible with the idea of > wrapping different types of pointers, such as memory mapped files. > That's why I refer to it as a design flaw rather than a simple bug to > fix. > > Unfortunately I don't know what the solution would be. Under the > old-style rules, the lifetime for an NSData object would be fairly > predictable (previous examples in this thread have brought up release > messages being sent by other threads, but this would be wholly invalid > usage to begin with) thus it was safe to work with a pointer whose > lifetime was completely tied to it. Now the lifetime is not > predictable in the general case, even if you do everything else right, > so you have to work to make it be predictable. All we really need is for the GC to behave as documented: treat an object whose variable is on the stack frame as a root object. Hamish _______________________________________________ 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 [EMAIL PROTECTED]
