Re: Where's the buffer overrun?
Re: Where's the buffer overrun?
- Subject: Re: Where's the buffer overrun?
- From: "stephen joseph butler" <email@hidden>
- Date: Wed, 19 Mar 2008 20:22:57 -0500
On Wed, Mar 19, 2008 at 7:49 PM, Hamish Allan <email@hidden> wrote:
> On Thu, Mar 20, 2008 at 12:18 AM, Chris Suter
> <email@hidden> 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 (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
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden