This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425

--- Comment #8 from Filipe Brandenburger <filbranden at google 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.

I obviously *can* ignore the return value, just assign it to an unused variable
that I ignore...

By pretending that warn_unused_result can only be used in cases where the
return value can never be ignored with no exceptions (which, as mentioned
above, is not really impossible to enforce) you just end up making
-Wunused-result totally unusable.

> > This is an example of a *real* problem that would have been caught by
> > this warning:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c28
> 
> Except that assert definition is broken, the standard assert macro in C/C++
> does not have any side effects for NDEBUG.

My point was actually about:

  v.empty();   // v.clear() was intended!

Even without that assert() definition (which I imagine was done that way to
prevent breaking code that relied on the side effects of the expressions inside
it), it's basically impossible to enable it since then there's no good way
(except for the horrible bogus hacky ignored variable) to create exceptions to
the rule.

Just because this option was introduced 10 years ago, because you invented it
first, because you wrote unit tests to ensure this behavior, doesn't mean that
it's correct or that it's useful the way it is... Please reconsider.

I think it would be fine fine if you wanted to introduce an even stronger
__attribute__((error_unused_result)) or similar that allows no exceptions,
which could then be used for say malloc() or realloc() where there's really
*really* no excuse to not save the return value, but I really don't see the
point since there are always ways around it...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]