This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 11 Jun 2015 15:48:57 +0000
- Subject: [Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
- Auto-submitted: auto-generated
- References: <bug-66425-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I'd say that for any function for which use of this attribute is
appropriate, suppression of the warning should involve a detailed comment
explaining why the particular use of the function is so exceptional that,
very unusually, it is not possible to (for example) do anything useful
with the information that the function call failed or it is otherwise
exceptionally safe to ignore the result - and that any suppression of the
warning should involve extra-careful code review when added.
See, for example, how glibc handles use of diagnostic suppression pragmas,
via macros DIAG_PUSH_NEEDS_COMMENT, DIAG_IGNORE_NEEDS_COMMENT and
DIAG_POP_NEEDS_COMMENT, to make it extra-obvious if a patch is adding such
uses and to make it obvious at the use site that such comments are needed.
Now, the compiler cannot check whether an explanatory comment justifying
diagnostic suppression is present, and cannot know how a particular
project wishes to handle justifying exceptions to its normal coding style
rules. But it can make it as visible as possible that something unusual
and dubious is being done by ignoring the return value, to reduce the
chance of it slipping by reviewers.
I'd say that a warning suppressed by a (void) cast should be a separate
attribute, e.g. warn_unused_result_weak.