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.
After obsessing about this some more, I think I might have come to
much the same conclusion. The issue of whether the lifetime of a
variable *should* be identical to the scope of the variable seems
irresolvable, since there's no specification in control of the
compiler's behavior AFAIK.
Since 'data' is not referenced in or beyond the loop, we don't care
whether the NSData object gets garbage collected away or not after the
'bytes' assignment is made (so we don't care if the compiler shortens
the variable lifetime), so long as the memory pointed to by 'bytes'
doesn't disappear too.
The consequence of this should be either:
(a) [data bytes] must promise to return a collectable object (so that
the 'bytes' reference keeps it alive), or
(b) [data bytes] must lock (pseudo-retain) something internally
(possibly just 'data' itself) and be matched with an unlock (pseudo-
release) method.
(Maybe there's a 3rd option, but I can't think of it. Your custom
allocator suggestion is more or less equivalent to (b), I think.)
Case (a) would be nice for programmers, but I assume it isn't
implemented that way now for reasons of performance. Case (b) is
annoying to use, especially if you went to a GC-app to avoid worrying
about retain/release, but at least it's safe if coded correctly.
Since [data bytes] is neither (a) nor (b) right now, I'd suggest that
the defect is in the NSData API. Personally, I'd prefer (a), since I
never assumed anything about the performance of NSData allocations
anyway.
_______________________________________________
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
