Hi, > I would assume it’s because you aren’t checking the value of myBaseBufferPtr > after malloc returns. It could be nil there. So then later is the first place > you try to deref it (even though it’s now assigned to a new variable), so > that’s the first place a nil deref can be checked. You need to protect the > rest of the code from running if it’s nil up in your insertIndexes method. >
I was just about to post as I figured it out, the thing is that malloc should never return NULL and I thought the analyzer knew that, I guess it’s safer to test anyway. > BTW, I don’t want to start up the multiple returns discussion again, but if > you really must do it that way, at least add some obvious comments on each > one: > > if(blah) > return; // *** WARNING! Early return! *** > > That way people scanning your code will know there’s danger ahead, and won’t > spend hours trying to figure out why it never hits a breakpoint they might > have added down past the early returns they didn’t see. Yeah, it’s not finished yet, will comment it properly when I’ve finished it, that way I stand a chance of the comments matching the code, BTW, I don’t want to start up the worthless comments discussion again, But wrong comments are worthless comments! Cheers Dave _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
