Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Feb 2013 18:24:53 -0500
From: Rich Felker <>
Subject: Re: is musl run against cppcheck ?

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.