[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #15 from Lucas De Marchi lucas.de.marchi at gmail dot com --- (In reply to Manuel López-Ibáñez from comment #14) (In reply to Filipe Brandenburger from comment #12) Can I have this issue reopened please? If that makes you happy... Ok, how can we assign this bug to the appropriate team then? It doesn't work like that. Individual contributors will work on things that they find interesting or get paid to fix. Rusty, who opened this issue, seemed inclined to prepare such a patch. I can't really think of a situation in the Linux kernel source code where I'd find a __must_check function with a void cast, exactly for that reason, right now it would generate a warning. The users of _wur added _wur to a function expecting that any use of this function that does not assign the result will get a warning, even if there is a cast to void. Not warning for a cast to void breaks that expectation. As I said, the people who add the attribute may not be the same people who use the interface with that attribute. I myself when writing libraries use the _wur to give my users a warning if they are ignoring the return value. However they have all the rights to ignore it. Be it simply by not using -Wunused-result, hacking a macro to ignore the result or use the de facto standard to cast to void. IMO the latter is the best one since there might be 1 particular case in the entire codebase in which ignoring the return makes sense.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Lucas De Marchi lucas.de.marchi at gmail dot com changed: What|Removed |Added CC||lucas.de.marchi at gmail dot com --- Comment #10 from Lucas De Marchi lucas.de.marchi at gmail dot com --- (In reply to Andrew Pinski from comment #7) 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. You are ignoring the fact that the places in which the attribute is put is often out of control for those using that interface. This means they can't really remove the attribute or also that the attribute may make sense in MOST of the cases but not in that particular one. Casting to void is nowadays the de facto standard to say I really know what I'm doing and I don't care about the return value *here*. This is way better then letting each project invent their all workaround macros and even risk doing the wrong thing like the assert you pointed out as wrong. So maybe after 10 years it's time to revisit that decision? It's not that the behavior of when warnings are emitted are really set in stone and never changed. It pretty much did all this time and we kept adapting to it. If just changing the behavior is not acceptable then maybe splitting the -Wunused-result to let people ignore this particular case of cast to void as suggested would be good. The gcc vs clang vs linters debate and who invented the attribute don't belong to this discussion. It's better to discuss why we can't let the attribute be actually useful by letting the users to turn it off when they know what they are doing.
