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 (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
