All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@freedesktop.org>
To: Morten Welinder <mwelinder@gmail.com>
Cc: Alexey Dobriyan <adobriyan@sw.ru>,
	Al Viro <viro@ftp.linux.org.uk>,
	linux-kernel@vger.kernel.org, davej@codemonkey.org.uk,
	Pierre Ossman <drzeus@drzeus.cx>,
	akpm@osdl.org, linux-sparse@vger.kernel.org
Subject: Re: idio{,ma}tic typos (was Re: + fix-vm_can_nonlinear-check-in-sys_remap_file_pages.patch added to -mm tree)
Date: Wed, 10 Oct 2007 11:08:53 -0700	[thread overview]
Message-ID: <470D1535.6030708@freedesktop.org> (raw)
In-Reply-To: <118833cc0710100635x205503a2peb73d24384538afa@mail.gmail.com>

Morten Welinder wrote:
>> While we're at it, below is somewhat ugly sparse patch for detecting
>> "&& 0x" typos.
> 
> Excellent idea, and there is something to be said about a low-footprint patch
> like that.  However, if you really want to capture this kind of bugs, you would
> need to have some kind "not a boolean" or "bitfield" attribute that
> can propagate.
> For example, you would want
> 
>     if (foo && (BAR | BAZ)) ...;
> 
> with BAR and BAZ being hex constants to produce the same warning.
> 
> Incidentally, it is probably not just hex constants that deserve this treatment:
> octal constants and variations of (1 << cst) are of the same nature.  As well
> as enums defined in such manners.

Sparse has a notion of "integer constant expression" already, which it
uses to validate expressions used for things like bitfield widths or
array sizes.  I could easily have Sparse warn on any use of an integer
constant expression as an operand of || or &&.  However, I can imagine
that that might lead to some false positives when intentionally using
an integer constant expression in a condition and expecting the
compiler to optimize it out at compile time.

- Josh Triplett

  reply	other threads:[~2007-10-10 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-10 10:45 idio{,ma}tic typos (was Re: + fix-vm_can_nonlinear-check-in-sys_remap_file_pages.patch added to -mm tree) Alexey Dobriyan
2007-10-10 11:23 ` Andreas Schwab
2007-10-10 11:45 ` Josh Triplett
2007-10-11  7:35   ` Alexey Dobriyan
2007-10-11  9:00     ` Kyle Moffett
2007-10-11 16:27     ` Josh Triplett
2007-10-10 13:35 ` Morten Welinder
2007-10-10 18:08   ` Josh Triplett [this message]
2007-10-10 19:02     ` Pavel Roskin
2007-10-10 18:22 ` Pierre Ossman
2007-10-11 13:57   ` Alex Dubov

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=470D1535.6030708@freedesktop.org \
    --to=josh@freedesktop.org \
    --cc=adobriyan@sw.ru \
    --cc=akpm@osdl.org \
    --cc=davej@codemonkey.org.uk \
    --cc=drzeus@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=mwelinder@gmail.com \
    --cc=viro@ftp.linux.org.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.