git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Jeff King" <peff@peff.net>, "Johannes Sixt" <j.sixt@viscovery.net>
Cc: "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 21:53:35 +0100	[thread overview]
Message-ID: <6BDA2E3E7318418BBB2C19B475B2B118@PhilipOakley> (raw)
In-Reply-To: 20130716062122.GA4964@sigill.intra.peff.net

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

  reply	other threads:[~2013-07-16 20:53 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 [this message]
2013-07-16 21:18       ` Stefan Beller
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=6BDA2E3E7318418BBB2C19B475B2B118@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=peff@peff.net \
    --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).