[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878v4pwa9l.fsf@nemi.mork.no>
Date: Thu, 11 Apr 2013 13:56:54 +0200
From: Bjørn Mork <bjorn@...k.no>
To: Dave Jones <davej@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Joe Perches <joe@...ches.com>,
Andy Whitcroft <apw@...dowen.org>,
LKML <linux-kernel@...r.kernel.org>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [PATCH] checkpatch: Warn on comparisons to true and false
Dave Jones <davej@...hat.com> writes:
> On Wed, Apr 10, 2013 at 03:57:51PM -0700, Andrew Morton wrote:
> > On Tue, 09 Apr 2013 20:17:14 -0700 Joe Perches <joe@...ches.com> wrote:
> >
> > > Comparisons of A to true and false are better written
> > > as A and !A.
> > >
> > > Bleat a message on use.
> >
> > hm. I'm counting around 1,100 instances of "== true" and "== false".
> >
> > That's a lot of people to shout at. Is it really worthwhile?
> > "foo==true" is a bit of a waste of space but I can't say that I find it
> > terribly offensive.
>
> It would be interesting to see how many people have historically screwed
> up and used (!a) when they mean (a) and vice versa, versus spelling
> it out longform. I'd be surprised if the results weren't skewed
> in favour of the more verbose form.
You have to consider that it is still possible to reverse the operator
even if spelling it out, so you don't really gain anything:
bjorn@...i:/usr/local/src/git/linux$ git grep -E '!=\s*(true|false)'|wc -l
63
and since most of these compare to true, they are also at risk wrt
integers:
bjorn@...i:/usr/local/src/git/linux$ git grep -E '!=\s*true'|wc -l
54
Based on a quick look at a few of these I guess they are mostly OK,
testing against bool values. But I felt I had to share this little gem
which showed up in drivers/gpu/drm/exynos/exynos_drm_vidi.c:
static int vidi_power_on(struct vidi_context *ctx, bool enable)
{
struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
struct device *dev = subdrv->dev;
DRM_DEBUG_KMS("%s\n", __FILE__);
if (enable != false && enable != true)
return -EINVAL;
..
That's taking failsafe to the next step :)
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists