All of lore.kernel.org
 help / color / mirror / 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: 21+ 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
2008-04-25 16:34 Atsushi Nemoto
2008-04-27 17:33 ` Ralf Baechle
2005-10-02 16:16 Atsushi Nemoto
2005-10-03 10:40 ` Ralf Baechle

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=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.
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.