[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1336407634.18931.5.camel@joe2Laptop>
Date: Mon, 07 May 2012 09:20:34 -0700
From: Joe Perches <joe@...ches.com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Guenter Roeck <guenter.roeck@...csson.com>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
"James E.J. Bottomley" <JBottomley@...allels.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jarod Wilson <jarod@...hat.com>
Subject: Re: drivers: Probable misuses of ||
On Mon, 2012-05-07 at 09:36 +0100, Mark Brown wrote:
> On Sat, May 05, 2012 at 09:00:42AM -0700, Guenter Roeck wrote:
> > On Fri, May 04, 2012 at 06:13:33PM -0400, Mark Brown wrote:
>
> > > Right, but you need to look at the code and explain why this is a
> > > problem. For example, the case I've left quoted above reads to me like
> > > the intention is "If the chip isn't one I know doesn't like this then
> > > let's do it" which is a perfectly sensible thing to write.
>
> > I can not really follow your logic here; it is difficult for me to imagine a situation
> > where anything along the line of
> > if (val != 1 || val != 2)
> > would provide value other than creating confusion. Maybe you can explain that a bit further.
>
> Yeah, I hadn't actually read the code closely enough but it's not my
> main point anyway - the main point was that the reports were very easy
> to ignore because they're just a paste in of the error message
Nope, these were the original source codes.
> with no analysis
You did elide the "Likely the || should be &&" preface.
> they were very likely to just get ignored unless someone has a
> particular interest in the code (which is essentially what I did - I
> glanced at the report but only very briefly).
No worries, I miss things when I scan code too quickly
as well.
> Compare this with the reports from people like Julia Lawall, for example
> - they tend to be very clear. Even simply adding "...as with || they
> will always be true" would've helped.
I think it's a pretty basic logic error that most all
lkml readers should be able to identify most of the time.
cheers, Joe
--
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