From: Tomas Carnecky <tom@dbservice.com>
To: git list <git@vger.kernel.org>
Subject: clang static analyzer
Date: Sun, 6 Dec 2009 07:11:24 +0100 [thread overview]
Message-ID: <33ABC714-2BCC-4910-BCAE-D331AAF2A724@dbservice.com> (raw)
There have been several attempts at running the clang static analyzer on the git source code, some even resulted in patches. I tried it, too, and among the many false positives I think clang found a few real issues. The results can be seen at [1].
Clang again found many dead assignments/increments, but in the earlier discussions you concluded that you want to keep those around. So I focussed on another class of potential bugs: Argument with 'nonnull' attribute passed null. There were a total of seven such issues. I then tried to look through the code and see if they are valid or false positives:
xdiff-interface.c:xdiff_set_find_func() - When 'value' is a string with no newline character in it, the loop at line 291 sets 'value' to NULL on its first iteration and then passes 'value' to strchr() in the second iteration.
utf8.c:utf8_strwidth() - 'string' may be set to NULL in utf8_width() which makes this one a false positive.
pretty.c:get_header() - if 'line' doesn't contain a newline character, line is set to NULL on first iteration and then passed to strchr() in the second itration.
attr.c:prepare_attr_stack() - bootstrap_attr_stack() sets attr_stack so this one is a false positive as well.
test-parse-options.c:length_callback() - if arg == NULL and unset == 0 then the function passes NULL to strlen().
builtin-pack-objects.c:check_pbase_path() - false positive, if done_pbase_paths == NULL then also done_pbase_paths_alloc == 0 and so step 4 can't take the false branch.
builtin-ls-files.c:verify_pathspec() - false positive, pathspec is not NULL when the function is called.
- Some of the issues might be purely hypothetical, for example I don't know if it's possible that get_header() can be passed a string with no newlines, maybe this is prevented earlier in the code path.
- Some of the false positives (such as the last one) could be avoided by giving clang a hint that a certain variable can't be NULL (by using assert() or if (!foo) return).
tom
[1] http://78.46.209.101/stuff/clang-static-analyzer/git/v1.6.6-rc1-32-g97f3d79/
next reply other threads:[~2009-12-06 6:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-06 6:11 Tomas Carnecky [this message]
2009-12-06 14:57 ` clang static analyzer Jeff King
2009-12-06 15:39 ` Nicolas Pitre
2009-12-06 16:04 ` Jeff King
2009-12-06 23:49 ` Nicolas Sebrecht
2009-12-07 0:18 ` Junio C Hamano
2009-12-07 0:26 ` Junio C Hamano
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=33ABC714-2BCC-4910-BCAE-D331AAF2A724@dbservice.com \
--to=tom@dbservice.com \
--cc=git@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