https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- Some remarks before the discussion gets out of hand. Neither Andrew nor me nor other people that may comment here have the power to approve or reject this change. 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. > 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. 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))" ? Perhaps you could ask GNU libc to provide such non-standard macro "ignore_unused_result" to avoid every project inventing their own. 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). > 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). > 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. That way of arguing is self-defeating, I'm sorry to say. The attribute is actually useful because people are using it, otherwise, you would not even have noticed that it exists.
