On Sat, Jun 7, 2008 at 8:47 AM, Hamish Allan <[EMAIL PROTECTED]> wrote: > 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.
What I'm saying is that the compiler+GC only guarantees that you have a strong reference to that object *while you're using it*. It's very easy to take the documentation and make a small leap to say that you have a strong reference to an object for as long as the function where the pointer is declared is on the stack, but that's not actually what it says. The business about scanning the stack is essentially an implementation detail; the promise that is being made is that objects which you're still pointing to won't go away. Once you pass the last reference to an object, all bets are off. >> 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?! How would it be less straightforward? If it returned collected memory then everything will Just Work for the common case of using the pointer on the stack. You would also have the additional convenience of being able to safely store the returned pointer in a __strong heap variable, something which you simply cannot do under non-GC rules at all. Looks like there are only improvements to me, where is the problem? > 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. It *does* do this. The error is not in the GC, but rather in the assumption that "declared in the current scope" is equivalent to "is on the stack frame". This assumption is not valid. The fact that you can't make this assumption is extremely inconvenient for the situation being discussed, but that doesn't mean that it's not behaving as documented. 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 [EMAIL PROTECTED]
