git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <stefanbeller@googlemail.com>
To: Philip Oakley <philipoakley@iee.org>
Cc: Jeff King <peff@peff.net>, Johannes Sixt <j.sixt@viscovery.net>,
	Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
	Junio C Hamano <gitster@pobox.com>,
	GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] Fix some sparse warnings
Date: Tue, 16 Jul 2013 23:18:53 +0200	[thread overview]
Message-ID: <51E5B8BD.8090202@googlemail.com> (raw)
In-Reply-To: <6BDA2E3E7318418BBB2C19B475B2B118@PhilipOakley>

[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]

On 07/16/2013 10:53 PM, Philip Oakley wrote:
> From: "Jeff King" <peff@peff.net>
> Sent: Tuesday, July 16, 2013 7:21 AM
>> On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
>>
>>> Am 7/15/2013 19:31, schrieb Ramsay Jones:
>>> > Sparse issues three "Using plain integer as NULL pointer" warnings.
>>> > Each warning relates to the use of an '{0}' initialiser expression
>>> > in the declaration of an 'struct object_info'.
>>>
>>> I question the value of this warning. Initialization with '= {0}' is
>>> a
>>> well-established idiom, and sparse should know about it. Also, plain
>>> 0
>>> *is* a null pointer constant.
>>
>> I agree with you. It's not a bug, and I think sparse is being overly
>> picky here; it is missing the forest for the trees in interpreting the
>> idiom.
>>
>> Still, it may be worth tweaking in the name of eliminating compiler
>> noise, since it does not cost us very much to do so (and I believe we
>> have done so in the past, too).
>>
>> We could also ask people with sparse to turn off the "use NULL instead
>> of 0" warning, but I think it _is_ a useful warning elsewhere (even
>> though it is never a bug, it violates our style guidelines and may be
>> an
>> indication of a bug). It would be nice if sparse learned to ignore the
>> warning in this particular idiom, but I am not going to hold my breath
>> for that.
>>
>> -Peff
>> -- 
> 
> On the subject of warnings and null pointers, yesterday's Code Project
> news linked to a blog on the problems of unexpected optimization bugs,
> such as dereferencing a null pointer. "Finding Undefined Behavior Bugs
> by Finding Dead Code" http://blog.regehr.org/archives/970 which links to
> the draft of an interesting paper
> [http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf]
> 
> Does anyone run the "new static checker called 'Stack' that precisely
> identifies unstable code"? [though the paper's conclusion says 'All
> Stack source code will be publicly available.' which suggests it's not
> yet available]
> 
> Or use the ‘-fno-delete-null-pointer-checks’ referred to in the blog
> comments (see also index : kernel/git/torvalds/linux.git "Add
> '-fno-delete-null-pointer-checks' to gcc CFLAGS"
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf
> 
> 
> You're probably already aware of these aspects but I thought it worth
> mentioning for the wider readership.
> 
> regards
> 
> Philip
> 
> 

I recently started contributing and I used cppcheck found at
https://github.com/danmar/cppcheck to submit the patches
at origin/sb/misc-fixes
As it is originally for C++, that tool throws lots of
false-positives (i.e. warns about null pointer dereferencing
when it's not possible to be a null pointer) unfortunately.

Also I hear llvm/clang comes with a good static code analyzer,
which I tried today on a different project.
Though I could not figure out how to use that on a pure C project
such as git, as that tool seems to require a C++ compilation for
doing its static code analysis.

The blog post you linked to seems very interesting and promising. :)

Regards,
Stefan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

  reply	other threads:[~2013-07-16 21:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-15 17:31 [PATCH] Fix some sparse warnings Ramsay Jones
2013-07-16  5:57 ` Johannes Sixt
2013-07-16  6:21   ` Jeff King
2013-07-16 20:53     ` Philip Oakley
2013-07-16 21:18       ` Stefan Beller [this message]
2013-07-16 22:18         ` Philip Oakley
2013-07-17  5:47         ` Johannes Sixt
2013-07-17 22:08       ` Stefan Beller
2013-07-17 22:09         ` [PATCH] parse_object_buffer: Correct freeing the buffer Stefan Beller
2013-07-17 22:16         ` [PATCH] Fix some sparse warnings Stefan Beller
2013-07-17 23:22         ` Junio C Hamano
2013-07-18 17:58     ` Ramsay Jones
  -- strict thread matches above, loose matches on Subject: below --
2013-07-18 20:25 Ramsay Jones
2013-07-18 20:36 ` Jeff King
2013-07-20 19:26   ` Ramsay Jones
2013-07-21 17:39 ` Jonathan Nieder
2013-07-21 20:58   ` 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

  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=51E5B8BD.8090202@googlemail.com \
    --to=stefanbeller@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=peff@peff.net \
    --cc=philipoakley@iee.org \
    --cc=ramsay@ramsay1.demon.co.uk \
    /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).