[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130228232453.GN20323@brightrain.aerifal.cx>
Date: Thu, 28 Feb 2013 18:24:53 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
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.
Rich
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.
