> On Jun 9, 2015, at 07:35:11, Dave <[email protected]> wrote:
>
> [self setupIndexBuffer];
> //This sets self.pIndexBaseBufferPtr to a buffer created with malloc()
> myDestIndexBufferPtr = self.pIndexBaseBufferPtr;
> *myDestIndexBufferPtr = myIndex;
> //********** Warning Dereference of null pointer (loaded from
> variable myDestIndexBufferPtr)
> The properties are defined as so:
>
> @property (nonatomic,assign) void*
> pIndexBaseBufferPtr;
> -(void) setupIndexBuffer
> {
> void* myBaseBufferPtr;
>
> if (self.pIndexBaseBufferPtr != NULL)
> free(self.pIndexBaseBufferPtr);
>
> self.pIndexBaseBufferSize = (self.pIndexMaximumLength * sizeof(NSUInteger));
> myBaseBufferPtr = malloc(self.pIndexBaseBufferSize);
> self.pIndexBaseBufferPtr = myBaseBufferPtr;
>
> [self clearIndexBuffer];
> }
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.
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.
--
Steve Mills
Drummer, Mac geek
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
