linux-kernel - Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100615134039.6ccfc17a@hyperion.delvare>
Date:	Tue, 15 Jun 2010 13:40:39 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	David Daney <david.s.daney@...il.com>
Cc:	"Justin P. Mattock" <justinmattock@...il.com>,
	linux-kernel@...r.kernel.org, reiserfs-devel@...r.kernel.org,
	linux-bluetooth@...r.kernel.org, clemens@...isch.de,
	debora@...ux.vnet.ibm.com, dri-devel@...ts.freedesktop.org,
	linux-i2c@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
	linux-media@...r.kernel.org
Subject: Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but 
 not used

Hi David,

On Mon, 14 Jun 2010 14:28:57 -0700, David Daney wrote:
> On 06/14/2010 01:53 PM, Jean Delvare wrote:
> > Hi Justin,
> >
> > On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote:
> >> could be a right solution, could be wrong
> >> here is the warning:
> >>    CC      drivers/i2c/i2c-core.o
> >> drivers/i2c/i2c-core.c: In function 'i2c_register_adapter':
> >> drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used
> >>
> >>   Signed-off-by: Justin P. Mattock<justinmattock@...il.com>
> >>
> >> ---
> >>   drivers/i2c/i2c-core.c |    2 ++
> >>   1 files changed, 2 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >> index 1cca263..79c6c26 100644
> >> --- a/drivers/i2c/i2c-core.c
> >> +++ b/drivers/i2c/i2c-core.c
> >> @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
> >>   	mutex_lock(&core_lock);
> >>   	dummy = bus_for_each_drv(&i2c_bus_type, NULL, adap,
> >>   				 __process_new_adapter);
> >> +	if(!dummy)
> >> +		dummy = 0;
> >
> > One word: scripts/checkpatch.pl
> >
> > In other news, the above is just plain wrong. First we force people to
> > read the result of bus_for_each_drv() and then when they do and don't
> > need the value, gcc complains, so we add one more layer of useless
> > code, which developers and possibly tools will later wonder and
> > complain about? I can easily imagine that a static code analyzer would
> > spot the above code as being a potential bug.
> >
> > Let's stop this madness now please.
> >
> > Either __must_check goes away from bus_for_each_drv() and from every
> > other function which raises this problem, or we must disable that new
> > type of warning gcc 4.6.0 generates. Depends which warnings we value
> > more, as we can't sanely have both.
> >
> 
> That is the crux of the whole thing.  Putting in crap to get rid of the 
> __must_check warning someone obviously wanted to provoke is just plain 
> wrong.

__process_new_adapter() calls i2c_do_add_adapter() which always returns
0. Why should I check the return value of bus_for_each_drv() when I
know it will always be 0 by construction?

Also note that the same function is also called through
bus_for_each_dev() somewhere else in i2c-core, and there is no warning
there because bus_for_each_dev() is not marked __must_check. How
consistent is this? If bus_for_each_dev() is OK without __must_check,
then I can't see why bus_for_each_drv() wouldn't be.

> I don't know what the answer is, but in addition to your suggestion of 
> removing the __must_check, you might try:
> 
> BUG_ON(dummy != WHAT_IT_SHOULD_BE);
> 
> or
> 
> if (dummy != WHAT_IT_SHOULD_BE)
> 	panic("nice message here);

Which will never trigger.

> or
> 
> static inline void i_really_know_what_i_am_doing(int arg)
> {
> 	/*
> 	 * Trick the compiler because we don't want to
> 	 * handle error conditions.
> 	 */
> 	return;
> }
> 
> ..
> ..
> ..
> 
> 	i_really_know_what_i_am_doing(dummy);

Which is adding a lot of lines, and might eventually fail when the
compiler becomes smarter (if it isn't already). Thanks but no thanks.
If I really have to chose one of these evils, I'll go for BUG_ON(), at
least the intent is clear and the bloat is minimum.

-- 
Jean Delvare
--
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/