All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.ibm.com>
To: Lei YU <mine260309@gmail.com>, Ratan Gupta <ratagupt@linux.vnet.ibm.com>
Cc: "openbmc\@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Static code analysis tool for openbmc
Date: Thu, 14 Mar 2019 08:55:06 +1100	[thread overview]
Message-ID: <87lg1i4eyt.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAARXrt=knVzKw8HeiRi=XzZy322Sw12sevrWdgnuK82YHm1kiQ@mail.gmail.com>

Lei YU <mine260309@gmail.com> writes:
> On Wed, Mar 13, 2019 at 6:15 PM Ratan Gupta <ratagupt@linux.vnet.ibm.com> wrote:
>> Is there any plan to use any static code analysis tool in openbmc? I
>
> In Jenkins job, we have cppcheck to do checks on the code.
>
>> find one of the tool which is good and used in multiple opensource
>> projects is "coverity".
>
> I would prefer clang static analyzer, but other tools like coverity is also
> welcome.
> And if possible, there is much stronger analyzer PVS-Studio Analyzer (need
> license though). I read [PVS-Studio's blog][1] and that tool is really really
> good.
>
> But I think the main question is, what to do with issues found by the static
> analyzer? We need to define some rule to fix or ignore the issues.

In my experience with host firmware on OpenPOWER, each tool gets a
different set of things that it catches. Even the humble sparse catches
things that other tools do not (notably endian screw-ups).

A big advantage of Coverity is the tooling around it, the web site where
you can mark things permanently as a false positive, assign things to
people, etc. For other tools that you just run in a jenkins job, it's
way too easy to not see things grow, or just have a large list of false
positives you get used to ignoring.

-- 
Stewart Smith
OPAL Architect, IBM.

  reply	other threads:[~2019-03-13 21:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13 10:14 Static code analysis tool for openbmc Ratan Gupta
2019-03-13 13:43 ` Lei YU
2019-03-13 21:55   ` Stewart Smith [this message]
2019-03-14 16:26 ` Tanous, Ed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lg1i4eyt.fsf@linux.vnet.ibm.com \
    --to=stewart@linux.ibm.com \
    --cc=mine260309@gmail.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=ratagupt@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.