https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #78 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Andrew Church from comment #77)
> (In reply to Segher Boessenkool from comment #72)
> > if (foo()) {
> > /* The return value of foo can be ignored here because X and Y. */
> > }
>
> This is just another idiom, with "if(){}" replacing "(void)"; it does not
> directly indicate that the value is unused,
That is not what I said either, of course. It *does* give the author a great
place to add commentary why the return value is not actually used here. I.e.
the only thing that *actually matters*: it encourages one human (the author)
to communicate important information to the code reader.
Code is for humans to read (and write)! If you care about the compiler
first, you are doing it Wrong(tm).
> as a hypothetical [[discard]]
> would do. I would even argue that it is worse because (as Zdenek points
> out) it adds a branch which would either need to be tested, potentially
> requiring additional failure injection logic to trigger the failing case, or
> documented as not needing to be covered by a test.
If your coverage testing framework does not handle empty BBs specially, get
a better coverage framework.
> There's also an argument to be made that allowing the warning to be bypassed
> with if(){} or assignment to an unused variable is weakening the original
> intent behind WUR, as Jakub mentions.
It does the opposite, as I have explained many times now. I haven't seen Jakub
say anything like you say btw.
(I find the unused var thing just clumsy, noisy, inelegant, and distracting.
Not something someone who cares about readable code would ever do. There are
much better options!)
> The fundamental problem with the request behind this feature (in particular,
> with the fact that the request comes from a library author) is that the end
> user of the compiler is the library user, not the library author, and if the
> end user considers the warnings useless, they will find one or another way
> around them, however much collateral damage (in the form of missed errors)
> that may cause. Given that, I think it's reasonable to offer a
> middle-ground option that lets the end user reject the library author's
> original intent of forcing return value usage but retain the ability to
> check for accidentally unused return values.
The warning is exactly for cases like realloc(). If the user finds the warning
useless in that case, the user is a fool.
If someone (the user, the author, anyone) used warn_unused_result where it is
not appropriate, just fix *that*. The attribute is specifically for cases
where not looking at the result value is a big (often hard to find) bug, or
even a security problem. In cases where you just have some silly coding
standard
with silly rules you want to sillily follow, well, that is your own problem!
