Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27603

Re: Source code static analysis tool recommendations

Show key headers only | View raw

Am 03.02.2018 um 09:40 schrieb George Neuner:
> On Fri, 2 Feb 2018 17:13:40 -0800, John Speth <johnspeth@yahoo.com>
>> Thanks George.  The code is in C.  We'd like to run the tools on Windows 
>> computers.
>>
>> It happens that the first FDA submission was subject to only PC-Lint. 
>> The customer told me that the FDA did accept that test but I didn't 
>> believe it.  PC-Lint is not a deep testing tool, in my opinion.  I'll 
>> need to take a second look at that.
> 
> I haven't seen PC-Lint in many years, so I can't comment on that.
> Splint and cppcheck are free alternatives that are worth a look.  
> 
> There's an add-in that will integrate cppcheck into any recent Visual
> Studio edition.  Also VS Professional (or better) since 2013 has a
> pretty decent lint module included.

Not sure what lint module you're referring to, but Visual Studio has had
an "/analyze" option for quite some while. I remember there some tricks
circulating for enabling that on editions that did not officially
support it. One advantage that tool has over others is that it knows
Windows APIs, and finds things like "this API call returns a handle that
you should close if you don't need it".

The same thing can be said of cppcheck: it knows some POSIX APIs and
tells you you're leaking stuff.

> Splint works fine with VS, but there's no integration available AFAIK.
> You can use it as an external tool.
> 
> Synopsys's Coverity Scan is quite nice and decently comprehensive, but
> note that I only have used the free online version, which uploads your
> code to Synopsys's servers for analysis [and license-wise requires
> your project to be FOSS].  They do sell a version for proprietary use,
> but I have no knowledge of the cost.

Our company evaluated Coverity vs. Klocwork and ended up at Klocwork,
although I was not involved at the decision.

My main gripe with tools of that kind is that they have tons of checkers
and people turn them on all at once because they can. Klocwork literally
has something to say for every line of code, ending up with tens of
thousands of "issues" in a perfectly working software. Our QA people
defined a subset what to consider critical - about 1% of that - and even
of that remainder, in my team's software only 1% is actual problems, 50%
is style issues ("no 'break' after the last branch of this 'switch'",
"no '&' before this function name used as pointer"), and the remainder
is false positives ("please remove this check for errors, because I can
prove that this function call does not ever produce an error").

If my goal were getting better software, I'd start with turning up
compiler warnings to the max (warnings count as static analysis,
right?), unit tests with coverage analysis, valgrind, and an occasional
cppcheck or cl /analyze.

If the goal is to get a tool permanently into your workflow in a
documented way, a database-based tool like Klocwork doesn't sound too
bad, mainly because it has a way to re-identify findings across source
code changes (you need to tell it only once that that finding is a false
positive, not adjust a suppressions file after every edit). Just be
careful at what checkers you use and what to do about them. "Fix all
findings" is the wrong approach.


  Stefan

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 13:32 -0800
  Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-02 18:24 -0500
    Re: Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 17:13 -0800
      Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-03 03:40 -0500
        Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-03 11:45 +0100
        Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-03 16:37 +0000
          Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-04 10:18 +0100
            Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-04 15:12 +0000
              Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-05 18:48 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-05 23:18 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-06 19:25 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 22:53 +0100
                Re: Source code static analysis tool recommendations Richard Damon <Richard@Damon-Family.org> - 2018-02-06 21:34 -0500
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:06 +0100
                Re: Source code static analysis tool recommendations Jack <jack4747@gmail.com> - 2018-02-05 23:32 -0800
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 10:23 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-06 19:05 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 23:02 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-07 02:02 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:21 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-08 00:57 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-08 10:46 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-07 20:04 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 20:54 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-08 18:58 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-09 09:17 +0100
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:55 +1100
                Re: Source code static analysis tool recommendations Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-02-10 19:59 -0500
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:49 +1100

csiph-web