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é