[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

["pinskia at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Filipe Brandenburger from comment #6)
> Then please explain to me how this:
> 
>   (void) foo();
> 
> is any worse than this:
> 
>   int ignored __attribute__((unused));
>   ignored = foo();
>   /* do nothing with ignored here */
> 
> You can force me to assign the return value to something, but you can't
> really force me to do something useful with it...

I am not forcing you to do anything.  You (or others) are forcing yourself by
using this attribute.  GCC is not forcing you to use this attribute at all. 
You just don't the deinfition of the attribute which was decided on over 10
years ago.  Yes 10 years.  clang was not around back then.  So one could say
clang's attribute is not a copy of GCC's but rather a different one all
together.

> 
> In the cases above, I think the former is a much more clear way to express
> my intent to ignore that value, I'm telling the compiler "yeah, I know, I'm
> supposed to use this value, but in this particular case I really know what
> I'm doing so please bear with me here."
> 
> The -Wunused-result warnings would be a lot more useful (or, actually, just
> useful) if I was able to whitelist the places where I want to ignore the
> values, since right now my only practical choice is to disable it completely
> with -Wno-unused-result.
> 
> This is an example of a *real* problem that would have been caught by this
> warning:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c28

Except that assert definition is broken, the standard assert macro in C/C++
does not have any side effects for NDEBUG.  And actually that does not show a
real problem with the attribute but rather they have asserts which have side
effects so they worked out that problem by defining their own assert :).  Still
not a GCC bug :).

> 
> And it's not just LLVM... Other linters and static analysis tools seem to
> agree that a (void) cast is an explicit indication that the coder meant to
> ignore those results, so why would gcc want to be the one exception here?

Again this has nothing to do with other lints, this attribute was designed so
you can't ignore the return value.  And most lints/static analysis tools will
also look to see if you not really ignoring the return value in that you use it
in an error case fashion.  casting to void does not always cause (and really
should not cause) static analysis to ignore what you did was broken for the
API.  It is not GCC's fault people are starting to misuse this attribute; you
should write into those projects instead saying they are misunderstanding the
attribute is being used incorrectly.  I bet some of them, really don't want a
warning even with a cast to void.

> 
> Thanks!
> Filipe