From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Philip Oakley <philipoakley@iee.org>, "Koch\,
Rick \(Subcontractor\)" <Rick.Koch@tbe.com>,
Git List <git@vger.kernel.org>
Subject: Re: CPPCheck found 24 high risk bugs in Git v.1.8.3.4
Date: Mon, 19 Aug 2013 13:46:18 -0700 [thread overview]
Message-ID: <7vmwodl885.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130819204044.GA29258@sigill.intra.peff.net> (Jeff King's message of "Mon, 19 Aug 2013 16:40:44 -0400")
Jeff King <peff@peff.net> writes:
> On Mon, Aug 19, 2013 at 09:03:21PM +0100, Philip Oakley wrote:
>
>> In case other readers don't have a .xlsx reader here is Rick's list
>> in plain text (may be white space damaged).
>>
>> I expect some will be false positives, and some will just be being
>> too cautious.
>>
>> [...]
>>
>> description resourceFilePath fileName lineNumber
>> nullPointer(CppCheck) \git-master\builtin\add.c add.c 286
>
> Hm. That code in v1.8.3.4 reads:
>
> if (pathspec)
> while (pathspec[pc])
> pc++;
>
> What's the problem? If pathspec is not properly terminated, we can run
> off the end, but I do see anything to indicate that is the case. What
> does the "nullPointer" check mean here?
>
>> wrongPrintfScanfArgNum(CppCheck) \git-master\builtin\fetch.c
>> fetch.c 588
>
> Line 588 does not have formatted I/O at all. Are these line numbers
> somehow not matching what I have in v1.8.3.4?
>
>> nullPointer(CppCheck) \git-master\builtin\ls-files.c ls-files.c
>> 144
>
> This one looks like:
>
> if (tag && *tag && show_valid_bit &&
> (ce->ce_flags & CE_VALID)) {
> static char alttag[4];
> memcpy(alttag, tag, 3);
> if (isalpha(tag[0]))
>
> where the final line is 144. But we have explicitly checked that tag is not
> NULL...
>
>> doubleFree(CppCheck) \git-master\builtin\notes.c notes.c 275
>
> This one looks like:
>
> if (...) {
> free(buf);
> die(...);
> }
> ...
> free(buf);
>
> which might look like a double free if you do not know that die() will
> never return (it is properly annotated for gcc, but I don't know whether
> CppCheck understands such things).
>
> So out of the 4 entries I investigated, none of them looks like an
> actual problem. But I'm not even sure I am looking at the right place;
> these don't even seem like things that would cause a false positive in a
> static analyzer.
And the ones I picked at random looks totally bogus, too.
uninitvar(CppCheck) \git-master\notes.c notes.c 805
uninitvar(CppCheck) \git-master\notes.c notes.c 805
That is
int combine_notes_concatenate(unsigned char *cur_sha1,
const unsigned char *new_sha1)
{
char *cur_msg = NULL, *new_msg = NULL, *buf;
unsigned long cur_len, new_len, buf_len;
enum object_type cur_type, new_type;
int ret;
/* read in both note blob objects */
if (!is_null_sha1(new_sha1))
new_msg = read_sha1_file(new_sha1, &new_type, &new_len);
805: if (!new_msg || !new_len || new_type != OBJ_BLOB) {
free(new_msg);
return 0;
}
new_msg starts out to be NULL, if we did not run read_sha1_file(),
it will still be NULL and "if()" will not look at new_len/new_type
so their being uninitialized does not matter. If we did run
read_sha1_file(), and if it returns a non-NULL new_msg, both of
these are filled. If read_sha1_file() returns a NULL new_msg, again
the other two does not matter.
In short, the analyzer seems to be giving useless noise for this
one.
next prev parent reply other threads:[~2013-08-19 20:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-19 17:09 CPPCheck found 24 high risk bugs in Git v.1.8.3.4 Koch, Rick (Subcontractor)
2013-08-19 20:03 ` Philip Oakley
2013-08-19 20:40 ` Jeff King
2013-08-19 20:46 ` Junio C Hamano [this message]
2013-08-19 20:52 ` Johan Herland
[not found] ` <85C8141E5DAD94428A121F706995A31F010F116FDADE@MX1.net.tbe.com>
2013-08-19 21:46 ` Philip Oakley
2013-08-23 19:51 ` CPPCheck found 24 high risk bugs in Git v.1.8.3.4 (fetch.c L588) Philip Oakley
2013-08-19 22:55 ` CPPCheck found 24 high risk bugs in Git v.1.8.3.4 Philip Oakley
2013-08-19 23:15 ` Erik Faye-Lund
2013-08-20 14:33 ` Jeff King
2013-08-20 18:44 ` Andreas Schwab
2013-08-20 20:34 ` René Scharfe
2013-08-20 22:28 ` Erik Faye-Lund
2013-08-20 22:26 ` Erik Faye-Lund
2013-08-20 23:01 ` Andreas Schwab
2013-08-20 23:45 ` Junio C Hamano
2013-08-21 0:01 ` Erik Faye-Lund
2013-08-19 21:36 ` Stefan Beller
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vmwodl885.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Rick.Koch@tbe.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=philipoakley@iee.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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).