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

[David Brownell <david-b@pacbell.net>]

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