Linux SPARSE checker discussions
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Christopher Li <sparse@chrisli.org>
Cc: Linux-Sparse <linux-sparse@vger.kernel.org>
Subject: Re: [PATCH] Adding ignored attribute optimize
Date: Sun, 2 Jul 2017 21:58:19 +0200	[thread overview]
Message-ID: <20170702195818.2lhotikeq2ozjb2n@ltop.local> (raw)
In-Reply-To: <CANeU7Q=Zj6LT1--TP-XGouwVZVTgJor8h1+2GZ1r0HCjVa5pmw@mail.gmail.com>

On Sat, Jul 01, 2017 at 03:21:36PM -0700, Christopher Li wrote:
> On Sat, Jul 1, 2017 at 2:24 AM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> >
> > Sure it make some sense.
> >
> > But how often it happen and when it happen how much developers
> > are impacted and for how long?
> 
> It actually happen right now with the kernel using require_context
> which is not supported by sparse. Sparse should report error
> on the sparse related syntax which it does not support. Gcc is
> no going to report error on those sparse related attributes because
> gcc never see them.

"should report error" ...
What error exactly? Is there something that doesn't work on sparse
or on GCC's side regarding this 'require_context'? What need to be
fixed exactly?
 
> Because we have noway to tell an unknown attribute is belong
> to sparse or gcc.

That's *exactly* why sparse should *not* report. You have no way to
tell if what you're reporting is legitimate or not. And in most
cases it's legitimate on GCC's side but you still want to report it.

> Sparse checker should report it. It is very bad
> silence on those sparse specific error and developer have no way
> to know it.

It is very bad to report about all those false warnings.
It make sparse less usefull, not more.

> As for the distro version of sparse is too old.
> I think the right thing to do is just get into the habit of release
> more often.

Yes, it makes the problem worse, but even doing a release every
week won't change the problem when you take in account the lifetime
of distros.

If you want sparse to be usefull, you need to seek forward
compatibility and not blindly reporting lots of false warnings
for some very rare true ones.

But well ... let's agree we disagree.

-- Luc

  reply	other threads:[~2017-07-02 19:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 17:21 [PATCH] Adding ignored attribute optimize Christopher Li
2017-06-29  7:04 ` Luc Van Oostenryck
2017-06-29 21:46   ` Christopher Li
2017-07-01  9:24     ` Luc Van Oostenryck
2017-07-01 22:21       ` Christopher Li
2017-07-02 19:58         ` Luc Van Oostenryck [this message]
2017-07-03 18:23           ` Christopher Li
2017-07-03 20:41             ` Luc Van Oostenryck

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=20170702195818.2lhotikeq2ozjb2n@ltop.local \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox