On Sat, Jun 7, 2008 at 7:13 AM, Ken Thomases <[EMAIL PROTECTED]> wrote: > Nobody is claiming that it should. It's not about the char* pointer. It's > about the NSData* pointer.
Actually I think that it is about the char * pointer, and this bug should be considered an NSData bug rather than a compiler bug or a GC bug. The fact that it's really a design bug in NSData rather than something that can be easily fixed definitely makes it worse, but doesn't really change the location of the fault. The GC basically guarantees you that objects which you continue to use will continue to live until you're finished using them. Optimizations don't affect this at all; the compiler can't optimize away the storage of an object pointer until you're done using it. 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. 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. 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. Perhaps the solution would be for the GC to allow for collected memory with a custom allocator. This way NSData could always make the internal memory be collected, using the custom allocator to properly clean up for cases such as memory mapped files. 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]
