https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #12 from Filipe Brandenburger <filbranden at google dot com> --- (In reply to Manuel López-Ibáñez from comment #11) > Neither Andrew nor me nor other people that may comment here have the power > to approve or reject this change. Great, so please don't preemptively dismiss it as invalid. Can I have this issue reopened please? > The people you need to convince are the > C/C++ FE maintainers listed in the MAINTAINERS file. Some of them are also > GNU libc maintainers, thus actual users of the _wur attribute. We are just > trying to make you understand the context in which the decision *made by > others* has been made. Ok, how can we assign this bug to the appropriate team then? > This cannot be true, because the most heavy users of _wur are the kernel and > glibc, and the de-facto standard to compile those is GCC. > > How can "(void) foo(x)" be clearer than "ignore_unused_result(foo(x))" ? Maybe it's not *clearer* but the void cast is already a valid construct which is part of the language and will work regardless of which compiler and libc you use. I don't really see why the trouble making the mental connection from the void cast with the coder's intent do discard that result. Could it mean anything else really? > Perhaps you could ask GNU libc to provide such non-standard macro > "ignore_unused_result" to avoid every project inventing their own. The world doesn't really revolve around glibc you know? There are other libc's around as well... > Instead of '(void)', a patch that provides a __no_warn__ keyword as a > short-hand might be more acceptable (again, you don't have to convince us, > just the FE maintainers). Yeah maybe if we could go back in time 10 years that would have been sweet... But it seems the world has moved on and decided that the void cast is good enough, as code that uses it will work with any C compiler and any libc and the coder's intent is clear enough. > > 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. > > That is not so true, believe me. As someone that has been contributing to > GCC diagnostics for the last 10 years, changing GCC diagnostics ALWAYS > breaks someone's setup and they will be unhappy about it > (https://xkcd.com/1172/). > > That said, the best strategy to change the defaults is not to argue here in > this PR. The best strategy would be to collect the opinion from the most > heavy users of _wur (that is, GNU libc and the kernel maintainers, not their > users nor random people in their mailing lists), present a patch and argue > convincingly to the FE maintainers that this should change (not because > Clang is using it, but because the people using GCC want it). Please explain to me how changing this behavior could possibly break someone's code. If someone is already using -Wunused-result and using a void cast to try to silent the warning, they're failing to silent it on gcc, so if they're keeping the void cast around they're basically living with the warning and ignoring it... 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. So I don't understand what is the big deal about this one... Cheers, Filipe
