All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Beller <stefanbeller@gmail.com>
To: peff@peff.net, john@szakmeister.net, sam@vilain.net,
	GIT Mailing-list <git@vger.kernel.org>
Subject: scan.coverity: improve the modeling file of git.git
Date: Sun, 20 Jul 2014 23:44:53 +0200	[thread overview]
Message-ID: <53CC3855.8050500@gmail.com> (raw)

Hi Sam, John and Jeff,

I'm writing to you, as you're listed as the 
administrator of the git.git project 
on scan.coverity.com

We're currently seeing lots of false positives
as the xmalloc/xrealloc function is handled not properly
by coverity. There are lots of errors "Allocation too small for type"

Quoting (starting linenumbers are code) from some xrealloc ocurrence:


 95void *xrealloc(void *ptr, size_t size)
 96{
 97        void *ret;
 98
 99        memory_limit_check(size);
100        ret = realloc(ptr, size);

1. Condition "!ret", taking true branch   
2. Condition "!size", taking true branch

101        if (!ret && !size)
   
3. buffer_alloc: "realloc(void *, size_t)" which allocates 1 bytes based on "1UL".   
4. var_assign: Assigning: "ret" = storage allocated by "realloc(ptr, 1UL)".

102                ret = realloc(ptr, 1);
   
5. Condition "!ret", taking false branch

103        if (!ret) {
104                try_to_free_routine(size);
105                ret = realloc(ptr, size);
106                if (!ret && !size)
107                        ret = realloc(ptr, 1);
108                if (!ret)
109                        die("Out of memory, realloc failed");
110        }
   
6. return_dbuffer: Returning allocated array "ret".

111        return ret;
112}

However I have reviewed the function and I'd be pretty sure it would work as expected.
According to https://scan.coverity.com/tune we can upload a modelling file, 
which will allow us to supress such false positive errors.
I believe we'd need to put in the modelling file something like:

	// coverity[+alloc]
	void *xrealloc(void *ptr, size_t size);

and that should do. We'd not need to modify the git.git sources,
but just add such a declaration to the modelling file.

Does anyone of you administrators want to experiment with that?

Cheers,
Stefan

             reply	other threads:[~2014-07-20 21:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-20 21:44 Stefan Beller [this message]
2014-07-22  8:33 ` scan.coverity: improve the modeling file of git.git Jeff King

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=53CC3855.8050500@gmail.com \
    --to=stefanbeller@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=peff@peff.net \
    --cc=sam@vilain.net \
    /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.