On Wed, Mar 19, 2008 at 7:49 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 12:18 AM, Chris Suter > <[EMAIL PROTECTED]> wrote: > > > I think it's because > > > > [NSMutableData dataWithBytesNoCopy:returnArray length:length] > > > > is releasing returnArray and allocating a new buffer for it. > > I, for one, am surprised that NSMutableData works this way, given that > a) the method name specifically requests that no copy is made, and b) > there's no particular reason for it to behave that way unless the data > is resized. However, the following test code confirms it: Hmm... so I guess the solution is to move the +[NSMutableData dataWithBytesNoCopy:length:] call to the end. In addition, you can use NSData instead, which is what you really wanted anyway (I think). I question the wisdom of doing things this way -- using Foundation objects to "garbage collect" C data structures -- but it's not my API. Also, dataWithBytesNoCopy:length: says the data will be freed with free(). Is that really the same as NSZoneFree in all cases? I'm not sure. I find it strange that creating all sorts of autoreleased objects in the default zone doesn't matter, but the final array does. I'd recommend dropping the NSZoneMalloc here. _______________________________________________ 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]
