https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #46 from Andrew Church <achurch+gcc at achurch dot org> ---
(In reply to Andrew Pinski from comment #45)
> But there is no general agreement at all. If clang behavior agreed with gcc,
> then there would be consensus here. In fact gcc behavior is older than clang
> behavior makes this even more difficult and even points out that if clang
> said it implemented a compatible extension, it did not.
First, a single disagreement does not invalidate a consensus, at least in the
general meaning which I quoted ("the judgment arrived at by most of those
concerned" - note "most" and not "all"). As I discussed earlier, I still see
significantly wider support for the view that void casts should silence
discarded-value warnings, to the extent that I consider it fair to call that
view a consensus.
Second, an equally valid view of the meaning of Clang's behavior differing from
GCC's - barring any deeper knowledge of the LLVM team's decision-making, which
I do not have - is that the LLVM team merged the observed intent behind the
original extension (warn about values which should not be discarded) with its
knowledge of existing practice (use of a void cast to indicate a deliberately
discarded value) to arrive at their choice of behavior. If anything, I'd
suggest that https://bugs.llvm.org/show_bug.cgi?id=51228 being marked WONTFIX
because the developers consider it to be "working as intended" argues for this
view.
> You are basically saying all warnings will be ignored which is true.
That's not what I said, and I disagree at least with that particular phrasing.
I would, however, accept "warnings will be ignored if the user feels the effort
to fix the warning is not worth the benefit". By corollary, users in general
will take the path of least resistance to resolving a warning, and if allowing
void casts to silence specific instances of the warning encourages them to
leave the warning enabled in general, it will result in better code than if the
user gets so frustrated with the warning that they just turn it off completely.
> Using a void cast makes life too easy to ignore this behavior.
It still requires action on the part of the programmer. A programmer who
writes
system("foo");
may want to be warned that the return code from system() is discarded, whereas
a programmer who writes
(void) system("foo");
has clearly stated an intent to discard that return value, and warning about it
anyway is unnecessary noise. (Though an argument could be certainly be made
for a better word than "void", perhaps a construction like "[[discard]]
foo()".)
Is there a risk of cargo-cult syndrome? (A: "Hey B, how do I call this
external foo program?" B: "Just write '(void) system("foo")'.") Certainly.
But the same argument can be made for _any_ workaround, and I suspect that more
complex workarounds would increase, rather than decrease, that risk - the more
complex the code, the less likely the user is to read it and understand what
it's doing.
> If the api user wants to ignore the return
> values while the api developer tells you should not, then really the api
> user will have bugs. This is why the warning is there.
Demonstrably false (see above, and even your own caveat below).
> Now api developers
> have known to place this attribute on things that should not be placed on
> but that is not a compiler issue and the api user should talk with the api
> developer rather than try to change the compiler for their workaround.
Suppose the API developer's response is, "I don't care about your use case, I
want you to do things my way." What is the (non-compiler developer) user to do
then? Look for an alternative library, which may not even exist? Spend the
time to write their own? Disable the warning and accept the risk of bugs in
unrelated code? Look up the workaround du jour and throw it all over their
code base, cargo-cult style?
If I were faced with that choice, I would probably just switch to Clang.
