Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: Possible segfault introduced in commit.c

From: René Scharfe <hidden>
Date: 2016-06-15 22:53:40

Am 25.04.2012 13:14, schrieb Jeff King:
On Wed, Apr 25, 2012 at 12:59:28AM -0700, Michael Mueller wrote:
quoted
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é
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help