[PATCH] SPI: improve sysfs compiler complaint handling

[PATCH] SPI: improve sysfs compiler complaint handling

[Jeff Garzik]

Signed-off-by: Jeff Garzik <jeff@garzik.org>

---

Pointless?  I leave it up to the maintainer(s) to decide.

The compiler complains, even with the "(void)".

 drivers/spi/spi.c            |    4 +++-

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 146298a..085d4fa 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -448,7 +448,9 @@ static int __unregister(struct device *d
  */
 void spi_unregister_master(struct spi_master *master)
 {
-	(void) device_for_each_child(master->cdev.dev, NULL, __unregister);
+	int dummy;
+	
+	dummy = device_for_each_child(master->cdev.dev, NULL, __unregister);
 	class_device_unregister(&master->cdev);
 }
 EXPORT_SYMBOL_GPL(spi_unregister_master);

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[David Brownell]

On Wednesday 11 October 2006 6:49 pm, Jeff Garzik wrote:

> The compiler complains, even with the "(void)".

> -	(void) device_for_each_child(master->cdev.dev, NULL, __unregister);

Sure seems like a compiler bug to me.  For over two decades, casting
a value into the void has been a standard idiom for saying "ignore
that value" ... ISTR using it to get rid of "unused value" warnings
with LINT on BSD 4.1 systems.

Does anyone know why the GCC folk have decided to go against decades
of common practice here???

- Dave

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[Andrew Morton]

On Thu, 12 Oct 2006 11:08:59 -0700
David Brownell <david-b@pacbell.net> wrote:

> On Wednesday 11 October 2006 6:49 pm, Jeff Garzik wrote:
> 
> > The compiler complains, even with the "(void)".
> 
> > -	(void) device_for_each_child(master->cdev.dev, NULL, __unregister);
> 
> Sure seems like a compiler bug to me.

Seems like a kernel bug to me.  Look at device_del() and weep.  It calls
eighty eight things which can fail, some of which randomly return void but
shouldn't, then drops the overall result on the floor.

So if something failed and you come up and reinsert the device or driver
two days later the kernel collapses in a heap and you don't have a clue
why.

You're just a victim of all this.

Who wrote all this stuff, and what were they thinking?

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[David Brownell]

On Thursday 12 October 2006 11:24 am, Andrew Morton wrote:
> On Thu, 12 Oct 2006 11:08:59 -0700
> David Brownell <david-b@pacbell.net> wrote:
> 
> > On Wednesday 11 October 2006 6:49 pm, Jeff Garzik wrote:
> > 
> > > The compiler complains, even with the "(void)".
> > 
> > > -	(void) device_for_each_child(master->cdev.dev, NULL, __unregister);
> > 
> > Sure seems like a compiler bug to me.
> 
> Seems like a kernel bug to me.  Look at device_del() and weep.  It calls
> eighty eight things which can fail, some of which randomly return void but
> shouldn't, then drops the overall result on the floor.

That's an isssue too, but it's separate from the one I was describing
(wherein warnings are wrongly issued in the long-established idiom of
"casting into the void").  That compiler bug is causing lots of crap
to be added all over the kernel.

As you implicitly observed, the __unregister() routine really can't
do a thing with faults; it calls "void device_unregister()", which
in turn calls device_del() etc. 


> So if something failed and you come up and reinsert the device or driver
> two days later the kernel collapses in a heap and you don't have a clue
> why.
> 
> You're just a victim of all this.

Well, not me personally but "we" collectively as kernel developers.


> Who wrote all this stuff, and what were they thinking?

I suspect what they were thinking was the old "if you can't figure out
how to handle the error, don't test for it" thing.  I've never quite
agreed that so many cleanup-path routines should return void.  It's not
as if they _can't_ hit failures.  Or that some of those failures can't
be coped with by at stopping further attempts at cleanup...

- Dave

 

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[Arjan van de Ven]

> 
> > Who wrote all this stuff, and what were they thinking?
> 
> I suspect what they were thinking was the old "if you can't figure out
> how to handle the error, don't test for it" thing. 

the __must_check gcc feature was primarily designed to mark security
sensitive API's (such as copy_from_user) where you really do have to
check. Or cases where not checking/using is always a bug (realloc() in
userspace comes to mind).

It's OUR choice to mark the sysfs functions with this semantic, if we
don't want this strict warning we shouldn't use this attribute.

Based on many of the things that showed up so far, and Andrews comments,
I sort of get the feeling we DO want this behavior though...

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[Arjan van de Ven]

> Does anyone know why the GCC folk have decided to go against decades
> of common practice here???

because it's new semantics. I was involved in this GCC feature (not in
the coding just in the asking for it) and this behavior was specifically
requested: It is called __must_check, you MUST CHECK it. It's not the
normal "unused warning", by putting the attribute on the function you
tell gcc that the result MUST be checked. Just a cast to void isn't
checking it.... so it rightfully warns.

Re: [PATCH] SPI: improve sysfs compiler complaint handling

[David Brownell]

On Thursday 12 October 2006 11:39 am, Arjan van de Ven wrote:
> 
> > Does anyone know why the GCC folk have decided to go against decades
> > of common practice here???
> 
> because it's new semantics. I was involved in this GCC feature (not in
> the coding just in the asking for it) and this behavior was specifically
> requested: It is called __must_check, you MUST CHECK it. It's not the
> normal "unused warning", by putting the attribute on the function you
> tell gcc that the result MUST be checked. Just a cast to void isn't
> checking it.... so it rightfully warns.

Ah, I see.

So another issue would seem to be that this "__must_check" thing is now
being abused ... e.g. in cases like this one, where checking is pointless.

ISTR being frustrated at various points that GCC wouldn't warn when
function values were wrongly ignored.  Seems to me there are at least
four cases for function f() return values:

   f();			/* [1] not used ... worth warning about */

   (void) f();		/* [2] not used, but known to be OK; don't warn */

   value = f();		/* it's "used", assuming [3a] "value" is used
			 * instead of [3b] "value" is not used ... where
			 * "used" means more than just "assigned"
			 */

One of the issues with this __must_check() thing is that it's possible
to shut the warning up by assigning function results to a dummy value,
but then not use that value.  IMO that proliferates bad code.

IMO we'd have been a lot better off with the warnings on [1], which I
never recall seeing, and [3b], which we're clearly not seeing even now.
Because then we could shut up the "safe" warnings cleanly like [2], and
know that the real likely-to-be-bugs cases consistently trigger warnings.

- Dave