This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/35579] __attribute__(( warn_unused_result )) warns when it shouldn't, doesn't warn when it should
- From: "manu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Mar 2008 09:36:05 -0000
- Subject: [Bug c/35579] __attribute__(( warn_unused_result )) warns when it shouldn't, doesn't warn when it should
- References: <bug-35579-15916@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #3 from manu at gcc dot gnu dot org 2008-03-14 09:36 -------
(In reply to comment #2)
> >This is the design of warn_unused_result, you cannot ignore the value,
> >that is why casting to void does not work.
I agree with the reporter. There should be a way to tell the compiler to avoid
warning for particular cases. Casting to void seems to be the best way to do
that.
> >The warning happens in the front-end so we don't know if you really ignore the
> >value if you don't use the actually variable.
>
> Is there any way of fixing this? warn_unused_result is used in a number of
> quite significant pieces of code to enforce safety properties (the Linux kernel
> springs to mind), having a compiler-enforced safety check that doesn't work
> reliably seems rather dangerous. If it can't be fixed then could it at least
> be documented that the check isn't always reliable?
Unfortunately, the front-end lacks any data-flow knowledge, so this can't be
fixed. Almost all GCC warnings have the same limitations.
Documenting that warn_unused_result does not detect certain cases seems good.
Care to write a text? I will format it and submit it as a patch if you want.
Thanks.
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |manu at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-03-14 09:36:05
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35579