linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Carmody <phil@dovecot.fi>
To: Christopher Li <sparse@chrisli.org>
Cc: Josh Triplett <josh@joshtriplett.org>,
	Linux-Sparse <linux-sparse@vger.kernel.org>
Subject: Re: [PATCHv2 0/3] catch non-sign-extended '~' brainos
Date: Wed, 2 Jul 2014 12:28:53 +0300	[thread overview]
Message-ID: <20140702092853.GE19158@phil.dovecot.net> (raw)
In-Reply-To: <CANeU7Q=RV4xC8REQg_LP5VJz9-WB-+o6UEo5N2Fea9Y2WqdSnA@mail.gmail.com>

On Wed, Jul 02, 2014 at 01:51:25AM -0700, Christopher Li wrote:
> On Wed, Jul 2, 2014 at 12:43 AM, Phil Carmody <phil@dovecot.fi> wrote:
> >
> > Do you care about the precise type of the value?
> > If you do, then it may be ugly, but it's pretty much obligatory.
> > And if you don't care about the precise type...
> 
> Yes, I make a mistake on my macro. But alignment can be
> precise being unsigned. In a 32 bit system, what if I want to make
> a 2G align memory? Your signed alignment will force to be a
> negative value. Which is not precise.

You always have the option of an explicit size_t in that case.

> >> I don't consider alignment being 4U as wrong by itself. The key question
> >> is how you use it.
> >
> > Absolutely. And doing a ~ and then an up-cast is using it dangerously.
> > Isn't that what sparse is supposed to be checking for?
> 
> Well, you still need to get the false positive rate down. Currently then
> signal to noise ratio is too low. I would not recommend turning it on
> by default. Did you find some real bug in that 500 error report? Real
> bug I mean it produce actually bug on the object code it generated.

I'd like to say I found a real bug in an different open source package
with that check enabled. However, that's not true; I wrote that check
because I was perturbed that sparse hadn't found the bug which I'd just 
had to debug manually. So yes, it can catch real world issues.

It's much more likely to find issues in userspace programs, where there's
more likelyhood of wanting to allocate blocks of memory larger than 4G,
of course.

> >> if we introduce:
> >>
> >> #define ALIGNMASK(align)   (size_t)(~((align) -1))
> >>
> >> And we always use the macro to create mask from alignment value.
> >> Then there is no need to enforce signedness of the var passed into the
> >> macro. Hey, it might even read better.
> >
> > Put 4U in that, and it still has the flaw of creating a truncated mask.
> > Put 4 in and it doesn't.
> 
> Right, I make a mistake on that macro. Good catch.  How about
> 
> #define ALIGNMASK(align)   (~((size_t)((align) -1)))
> 
> Will you be happy if I use 4U with that macro?

Indeed. However, if the only use of the 4U is when it is expanded
into the expression (size_t)((4U) -1), then what was the 'U' again?
It still seems like a cargo cult artefact.

> My point is, with the right macro, you can still use 4U to create
> alignment. We don't have to fight over 4U vs 4.

Agreed. And how do you know if you've got the right macro?
It's on that question that I'd like sparse to step in and help.

Phil

      reply	other threads:[~2014-07-02  9:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 11:57 [PATCH 0/3] catch non-sign-extended '~' brainos Phil Carmody
2014-06-09 11:58 ` [PATCH 1/3] sparse: Just use simple ints for decision variables Phil Carmody
2014-06-09 11:58   ` [PATCH 2/3] sparse: detect non-sign-extended masks created by '~' Phil Carmody
2014-06-09 11:58     ` [PATCH 3/3] validation: dubious bitwise operations with nots Phil Carmody
2014-06-09 13:36       ` Josh Triplett
2014-06-09 13:34     ` [PATCH 2/3] sparse: detect non-sign-extended masks created by '~' Josh Triplett
2014-06-09 16:05       ` Phil Carmody
2014-06-09 13:27   ` [PATCH 1/3] sparse: Just use simple ints for decision variables Josh Triplett
2014-06-10  7:54 ` [PATCHv2 0/3] catch non-sign-extended '~' brainos Phil Carmody
2014-06-10  7:54   ` [PATCHv2 1/3] sparse: Just use simple ints for decision variables Phil Carmody
2014-06-10  7:54     ` [PATCHv2 2/3] sparse: detect non-sign-extended masks created by '~' Phil Carmody
2014-06-10  7:54       ` [PATCHv2 3/3] validation: dubious bitwise operations with bitwise nots Phil Carmody
2014-06-27 11:19   ` [PATCHv2 0/3] catch non-sign-extended '~' brainos Phil Carmody
2014-06-27 17:16     ` Christopher Li
2014-06-30  8:56       ` Phil Carmody
     [not found]         ` <CANeU7Q=Z=Xac_T3JRAyqo_fF4LAKD-MM41NYz+nDstDutcVUfA@mail.gmail.com>
2014-06-30 17:27           ` Christopher Li
2014-07-01 11:30           ` Phil Carmody
2014-07-01 19:42             ` Christopher Li
2014-07-02  7:43               ` Phil Carmody
2014-07-02  8:51                 ` Christopher Li
2014-07-02  9:28                   ` Phil Carmody [this message]

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=20140702092853.GE19158@phil.dovecot.net \
    --to=phil@dovecot.fi \
    --cc=josh@joshtriplett.org \
    --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;
as well as URLs for NNTP newsgroup(s).