Message-ID: <4BCD9E4E.9050309@gmail.com>
Date: Tue, 20 Apr 2010 13:30:06 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cppcheck bugs
References: <20100419211600 DOT 197240 AT gmx DOT net>
In-Reply-To: <20100419211600.197240@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 19/04/2010 22:16, Martin Ettl wrote:
> Hello,
> 
> you ever run a static code analysis tool on cygwin sources. I have done
> that! I used cppcheck
> (http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page)
> and got the following SEVERE warning messages:

  Now you know why people don't bother with those tools very often.  The noise
from false positives is awful!

> [fgetws.c:137]: (Error) Array index -1 corresponds with 4294967295, which is likely out of bounds

  All these are bogus.

> [../posix/regcomp.c:2005]: (Error) Memory leak: pmatches
> [../locale/ldpart.c:124]: (Error) Deallocating a deallocated pointer: lbuf
> [../stdlib/mallocr.c:2991]: (Error) Memory leak: newmem

  Might be real.

> [../machine/mips/strncpy.c:205]

  Uhh, why is it telling us about the MIPS-only version of strncpy in newlib
that we don't even compile in?

> [../search/hash_buf.c:153]: (Error) Uninitialized variable: segment_ndx
> [../../../winsup/utils/mount.cc:600]: (possible style) 

  It appears to have included style issues in its definition of "SEVERE"!

> [../../../winsup/utils/dump_setup.cc:153]: (Error) Uninitialized variable: buf
> [../../../winsup/utils/cygpath.cc:1106]: (Error) Resource leak: fp
> [../../../winsup/utils/cygcheck.cc:709]: (Error) Memory leak: sections
> [../../../winsup/utils/cygcheck.cc:1161]: (Error) Mismatching allocation and deallocation: f
> [../../../winsup/utils/cygcheck.cc:1168]: (Error) Mismatching allocation and deallocation: f
> [../../../winsup/utils/cygcheck.cc:1159]: (Error) Resource leak: f

  Various of these are probably real but probably don't matter because it's a
one-shot sort of application where it's about to exit and everything will be
freed anyway, so they're really style issues.

> [../../../winsup/mingw/mingwex/gdtoa/arithchk.c:182]: (Error) Resource leak: f
> [../../../winsup/mingw/profile/gmon.c:108]: (Error) Memory leak: cp
> [../../../winsup/mingw/profile/gmon.c:265]: (Error) Resource leak: log
> [../../../winsup/cygwin/gmon.c:257]: (Error) Resource leak: log

  That one could matter; one to look into next time someone's trying to fix
the bitrot in profiling.

> [../../../winsup/cygwin/regex/regcomp.c:1806]: (Error) Memory leak: pmatches

  Ooh, that one's real.  But will only happen if you're almost completely out
of memory anyway.

> [../../../winsup/cygwin/child_info.h:65]: (Error) Class child_info which is inherited by class child_info_spawn does not have a virtual destructor

  Pretty sure it's meant to be that way for a reason.

> [../../../winsup/cygwin/path.cc:2819]: (Error) Memory leak: to

  That one could just about be triggered if you deleted a mount point in
between the first and second calls to cygwin_conv_path in cygwin_create_path,
but it's pretty implausible.

  So, the main thing is that just running these tools isn't very useful by
itself, and what you get is a huge list of output, every one of which you have
to manually inspect and study the code, and most of which don't turn out to be
real bugs at all.  It's not a high priority for most folks when there are
usually already always real known bugs to be fixing!

    cheers,
      DaveK


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple