# Git's static analysis

3 messages from 2009-02-05 to 2009-02-06. Participants: Pieter de Bie, Junio C Hamano, Robin Rosenberg.
Thread: https://gitlist.dev/t/17596

## Pieter de Bie, 2009-02-05 21:40

Subject: Git's static analysis
Message-ID: <1233870004-63540-1-git-send-email-pdebie@ai.rug.nl>
URL: https://gitlist.dev/e/1233870004-63540-1-git-send-email-pdebie%40ai.rug.nl

```
Hi all,

I played around a bit with the 'Clang' static analyser, and tried to run git's
source code through it. It comes up with a few possible errors, so I thought
you might find it interesting. I took a quick glance, and it also seems to
have a few false positives, but it might still be worth to take a look.

The results can be found here:

	http://frim.frim.nl/git-analyse/

- Pieter

```

## Junio C Hamano, 2009-02-06 01:19

Subject: Re: Git's static analysis
Message-ID: <7v63jo9xbg.fsf@gitster.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v63jo9xbg.fsf%40gitster.siamese.dyndns.org
In-Reply-To: <1233870004-63540-1-git-send-email-pdebie@ai.rug.nl>

```
Pieter de Bie <pdebie@ai.rug.nl> writes:

> I played around a bit with the 'Clang' static analyser, and tried to run git's
> source code through it. It comes up with a few possible errors, so I thought
> you might find it interesting. I took a quick glance, and it also seems to
> have a few false positives, but it might still be worth to take a look.
>
> The results can be found here:
>
> 	http://frim.frim.nl/git-analyse/

Hmm, I took a quick look at a few, and they looked nonsense, but perhaps I
am misreading things.

For example:

    http://frim.frim.nl/git-analyse/report-uxXiUR.html#EndPath

I am assuming that we follow the control flow of the labelled comments, so
I followed along from [1] to [7] and then saw these:

    [8] loop condition is false, execution continues on line 1492
    1483:   for (i = 0; i < array->nr; i++) {
                ...
            }

    [9] taking false branch
    1492:   if (array->nr <= i)
                return NULL;

    [10] dereference of null pointer.
    1495:   c->object.flags |= ...

The thing is, if [8] exits, "i < array->nr" is not true anymore, and there
is no way you can take false branch of  "if (array->nr <= i)" in the
immediately next step [9]. and reach point [10].

So it is either that the tool does not know how "for" and "if" statement
works in C language, or I am completely misunderstanding what the in-line
comments are trying to tell me.

```

## Robin Rosenberg, 2009-02-06 06:11

Subject: Re: Git's static analysis
Message-ID: <200902060711.37191.robin.rosenberg.lists@dewire.com>
URL: https://gitlist.dev/e/200902060711.37191.robin.rosenberg.lists%40dewire.com
In-Reply-To: <7v63jo9xbg.fsf@gitster.siamese.dyndns.org>

```
fredag 06 februari 2009 02:19:15 skrev Junio C Hamano:
> Pieter de Bie <pdebie@ai.rug.nl> writes:
> 
> > I played around a bit with the 'Clang' static analyser, and tried to run git's
> > source code through it. It comes up with a few possible errors, so I thought
> > you might find it interesting. I took a quick glance, and it also seems to
> > have a few false positives, but it might still be worth to take a look.
> >
> > The results can be found here:
> >
> > 	http://frim.frim.nl/git-analyse/
> 
> Hmm, I took a quick look at a few, and they looked nonsense, but perhaps I
> am misreading things.
> 
> For example:
> 
>     http://frim.frim.nl/git-analyse/report-uxXiUR.html#EndPath
> 
> I am assuming that we follow the control flow of the labelled comments, so
> I followed along from [1] to [7] and then saw these:
> 
>     [8] loop condition is false, execution continues on line 1492
>     1483:   for (i = 0; i < array->nr; i++) {
>                 ...
>             }
> 
>     [9] taking false branch
>     1492:   if (array->nr <= i)
>                 return NULL;
> 
>     [10] dereference of null pointer.
>     1495:   c->object.flags |= ...

> 
> The thing is, if [8] exits, "i < array->nr" is not true anymore, and there
> is no way you can take false branch of  "if (array->nr <= i)" in the
> immediately next step [9]. and reach point [10].

The code assumes can c become null in the loop [if (!c) continue]. If that
is the last iteration it comes out of the loop with c == NULL and array->nr >=i,
thus not returning. 

I have to dig through history until may 2008 to find this version of this code  so
the analysis seems a bit obsolete. The loop was rewritten in 4603ec0f960e.

-- robin

```