From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Wed, 25 Apr 2012 20:22:34 GMT
Subject: Re: Possible segfault introduced in commit.c
Message-ID: <4F985D0A.9020100@lsrfire.ath.cx>
In-Reply-To: <20120425111435.GA21579@sigill.intra.peff.net>

Am 25.04.2012 13:14, schrieb Jeff King:
> On Wed, Apr 25, 2012 at 12:59:28AM -0700, Michael Mueller wrote:
>
>> As you might already know, we analyze git regularly with Sentry (our
>> static analysis tool).  Today it picked up a new NULL pointer
>> dereference in commit.c:366:
>>
>>      void commit_list_reverse(struct commit_list **list_p)
>>      {
>>          struct commit_list *prev = NULL, *curr = *list_p, *next;
>>
>>          if (!list_p)
>>              return;
>>          /* function continues... */
>>      }
>>
>> list_p is dereferenced on the first line, then tested for NULL on
>> the very next statement.  If it's possible that list_p is NULL, this
>> will be a segfault.  If it can't be NULL, then the check is
>> unnecessary (and probably misleading).
>
> Yes, you're right. There is only one caller currently, and it can never
> be NULL (it passes the address-of a pointer variable). I think dropping
> the NULL-check is the right thing; even an empty list will still have a
> pointer to its NULL head.

More often then not, a mistake like that is surrounded by other issues. 
  No, I didn't put it there intentionally to prove this point. ;-)

Having to reverse the list at all is unfortunate and I only did that 
because I thought appending would be more complicated and because we are 
going to replace the linked list with a different data structure soon 
anyway.  Turns out appending is easy.  Patches to follow.

René