On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
The garbage collector does not currently interpret inner pointers as something that can keep an encapsulating object alive. Thus, the behavior is undefined and that it changes between debug and release builds -- between optimization levels of the compiler -- is neither surprising nor considered to be a bug.
Yes, it's certainly not the "inner" pointer's job to keep the object alive. I can't help feeling that it would make sense for the lifetime of the object pointer variable to be the same as its scope. (I have no idea if there's any language specification that deals with this.) If there's any compiler bug, it's the optimization that shortens the object pointer variable lifetime that's at fault.
In any case, you need to make sure that <data> stays alive throughout the entire lifespan of the bytes pointer.
But the puzzling question is: how? Anything involving stack variables could potentially be optimized away. I could move the collectable object pointer into a global or instance variable, but that solution comes unglued as soon as I hit a case where the containing method is called recursively. I suppose a file static NSMutableSet temporarily holding collectable objects would work.
_______________________________________________ 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]
