smatch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: smatch@vger.kernel.org
Subject: Re: uninitialized symbol 'xxxx' is too overzealous?
Date: Mon, 28 May 2018 10:45:27 +0300	[thread overview]
Message-ID: <20180528074527.hm2vlzhxmh6aeyyi@mwanda> (raw)
In-Reply-To: <100457A5-2671-43E4-9E7D-CB3AD8DEB4FF@linuxhacker.ru>

On Fri, May 25, 2018 at 07:46:41PM -0400, Oleg Drokin wrote:
> 
> > On May 25, 2018, at 8:20 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > 
> > Btw, on my system the main cause of false positives with that test is
> > when people mix "if (ret)" and "if (ret < 0)".
> > 
> > When I run smatch, I rebuild the database every morning.  Every time you
> > rebuild it builds the call tree more and more.  So, for most functions,
> > Smatch eventually figures out all the possible returns and it doesn't
> > matter if you check for negatives or non-zero.  There are still some
> > functions which Smatch can't figure out, like there is recursion or if
> > we copy the error code from another thread.  I manually hack some of the
> > most problematic in smatch_data/db/kernel.return_fixes.
> 
> You mean if you run the rebuild db more than once in a row, the result
> becomes better what’s the number of times to run to get the best result?

The results do become better...  Say you have code which is inconsistent
about "if (ret)" and "if (ret < 0)", then it will complain after the
first build.  But eventually it will figure out the whole call tree and
that none of the functions return positive values so checking for
negatives is the same as checking for non-zero.  Normally a call chain
is 5-7 functions max, but Smatch parses some inline functions without
needing the cross function DB so it's figures out the call tree after
probably 4 DB rebuilds.

> Because otherwise I am typically doing a rebuild either once a day

If you're rebuilding the DB once a day, that's what I'm doing too so it
should be fine.

But really you shouldn't be getting that warning with the latest code at
any point I think.  Let me know if it still shows up and I'll
investigate.

regards,
dan carpenter


      reply	other threads:[~2018-05-28  7:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-18  0:55 uninitialized symbol 'xxxx' is too overzealous? Oleg Drokin
2018-05-25 12:12 ` Dan Carpenter
2018-05-25 23:43   ` Oleg Drokin
2018-05-25 12:20 ` Dan Carpenter
2018-05-25 23:46   ` Oleg Drokin
2018-05-28  7:45     ` Dan Carpenter [this message]

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=20180528074527.hm2vlzhxmh6aeyyi@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=green@linuxhacker.ru \
    --cc=smatch@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).