is musl run against cppcheck ?

is musl run against cppcheck ?

[Roger Sibert]

Hello Everyone,

I was just looking at musl to help with static compiled binaries for
systems that use CF cards for the base OS, I always run code against
cppcheck prior to use so that up front I know what may have to explain
to someone.

In running against an older version of cppcheck, my main system is
being rebuilt and the backup hasnt been upgraded yet, I ran across the
following

[src/network/getaddrinfo.c:115]: (error) Null pointer dereference
[src/network/if_nameindex.c:52]: (error) Memory leak: p
[src/thread/sem_open.c:45]: (error) Possible null pointer dereference:
semtab - otherwise it is redundant to check if seis null at line 45

My coding experience is spotty and I know cppcheck can throw false
positives so instead of guessing I wanted to see if the musl code had
been run through cppcheck.

I ran the below but just filtered out some of the possible/probably
false positives, though the ones referring to ccosh.c might be real.

/musl# script -c "/root/cppcheck --force --enable=all ."
cppcheck-output-musl.txt

Thanks,
Roger

Re: is musl run against cppcheck ?

[John Spencer]

On 02/28/2013 03:54 PM, Roger Sibert wrote:
> Hello Everyone,
>
> I was just looking at musl to help with static compiled binaries for
> systems that use CF cards for the base OS, I always run code against
> cppcheck prior to use so that up front I know what may have to explain
> to someone.
>
> In running against an older version of cppcheck, my main system is
> being rebuilt and the backup hasnt been upgraded yet, I ran across the
> following
>
> [src/network/getaddrinfo.c:115]: (error) Null pointer dereference
> [src/network/if_nameindex.c:52]: (error) Memory leak: p
> [src/thread/sem_open.c:45]: (error) Possible null pointer dereference:
> semtab - otherwise it is redundant to check if seis null at line 45

if musl deref's a null pointer, it is mostly to conciously cause a crash.
however, i think it should call a_crash() instead.

> My coding experience is spotty and I know cppcheck can throw false
> positives so instead of guessing I wanted to see if the musl code had
> been run through cppcheck.

yes. it was run a couple of time in the past.
for example this commit here fixed a commit that removed "unused code" 
wrongly detected by cppcheck.
http://git.musl-libc.org/cgit/musl/commit/?id=ae4b0b96d63fe3cbd70008350f998570c9e91f7f
> I ran the below but just filtered out some of the possible/probably
> false positives, though the ones referring to ccosh.c might be real.
>
> /musl# script -c "/root/cppcheck --force --enable=all ."
> cppcheck-output-musl.txt
>
> Thanks,
> Roger
>

Re: is musl run against cppcheck ?

[nwmcsween]

I'd recommend running the clang static analyzer if you can and hosting the resulting web view of it if you can. Iirc the static analyzer found bugs the last time.

Sent from my iPhone

On Feb 28, 2013, at 7:49 AM, John Spencer <maillist-musl@barfooze.de> wrote:

> On 02/28/2013 03:54 PM, Roger Sibert wrote:
>> Hello Everyone,
>> 
>> I was just looking at musl to help with static compiled binaries for
>> systems that use CF cards for the base OS, I always run code against
>> cppcheck prior to use so that up front I know what may have to explain
>> to someone.
>> 
>> In running against an older version of cppcheck, my main system is
>> being rebuilt and the backup hasnt been upgraded yet, I ran across the
>> following
>> 
>> [src/network/getaddrinfo.c:115]: (error) Null pointer dereference
>> [src/network/if_nameindex.c:52]: (error) Memory leak: p
>> [src/thread/sem_open.c:45]: (error) Possible null pointer dereference:
>> semtab - otherwise it is redundant to check if seis null at line 45
> 
> if musl deref's a null pointer, it is mostly to conciously cause a crash.
> however, i think it should call a_crash() instead.
> 
>> My coding experience is spotty and I know cppcheck can throw false
>> positives so instead of guessing I wanted to see if the musl code had
>> been run through cppcheck.
> 
> yes. it was run a couple of time in the past.
> for example this commit here fixed a commit that removed "unused code" wrongly detected by cppcheck.
> http://git.musl-libc.org/cgit/musl/commit/?id=ae4b0b96d63fe3cbd70008350f998570c9e91f7f
>> I ran the below but just filtered out some of the possible/probably
>> false positives, though the ones referring to ccosh.c might be real.
>> 
>> /musl# script -c "/root/cppcheck --force --enable=all ."
>> cppcheck-output-musl.txt
>> 
>> Thanks,
>> Roger
> 

Re: is musl run against cppcheck ?

[Rich Felker]

On Thu, Feb 28, 2013 at 09:54:03AM -0500, Roger Sibert wrote:
> Hello Everyone,
> 
> I was just looking at musl to help with static compiled binaries for
> systems that use CF cards for the base OS, I always run code against
> cppcheck prior to use so that up front I know what may have to explain
> to someone.

Thanks. I've reviewed them and none of them seem indicative of bugs.
See below:

> In running against an older version of cppcheck, my main system is
> being rebuilt and the backup hasnt been upgraded yet, I ran across the
> following
> 
> [src/network/getaddrinfo.c:115]: (error) Null pointer dereference

This is cppcheck being idiotic. It's treating a[b] as a dereference of
a, rather than treating it as *(a+b). Of course one could argue that
musl should not be using this arcane application of the [] operator...
but it's definitely not a null pointer dereference; it's a zero-offset
array reference.

> [src/network/if_nameindex.c:52]: (error) Memory leak: p

This is not a memory leak. cppcheck seems to be assuming any return
value other than 0 from do_nameindex is an allocation; this is not the
case. (void*)-1 is a sentinel, so discarding the pointer p when it
compares equal to (void*)-1 is not leaking allocated memory.

> [src/thread/sem_open.c:45]: (error) Possible null pointer dereference:
> semtab - otherwise it is redundant to check if seis null at line 45

This looks like a cppcheck bug: considering the *semtab argument of
the sizeof operator as a dereference. It's not because the expression
that's the operand of sizeof is never evaluated.

Rich