This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/71402] -Wunused-variable warnings ignore initialization side effects
- From: "andysem at mail dot ru" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 08 Jun 2016 17:17:20 +0000
- Subject: [Bug c++/71402] -Wunused-variable warnings ignore initialization side effects
- Auto-submitted: auto-generated
- References: <bug-71402-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71402
--- Comment #6 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #5)
> I understand that and agree that there is a set of use cases where users
> don't expect a warning. There is also another set of cases where a warning
> would be helpful: If the unused variable in the submitted test case were
> the result of code changes that removed its uses and the variable was left
> defined unintentionally, the user would be served by having this pointed
> out. Otherwise the dynamic initialization would waste resources.
I think issuing a warning about a perfectly valid code with no reasonable
confidence about the code being written by mistake does a poor job for the user
and encourages him to just disable the warning (possibly missing the real
mistakes that would have been highlighted by the warning).
> Adding a new warning (let's call it
> -Wunused-varible-with-dynamic-initializer) would be one way to provide the
> functionality that I think would be of use.
If the warning for a variable that has dynamic initialization is indeed
considered useful then I vote for the new flag solution. But frankly I think in
practice this warning would be next to useless (e.g. it would have to highlight
almost every mutex lock or scope guard).
> Another solution would be to issue the -Wunused-variable warning for the
> submitted test case and recommend users to annotate otherwise unused
> variables with attribute unused to suppress the warning. This approach
> would also be in line with the intended use of the new (in C++ 17)
> maybe_unused attribute (proposed in WG21 document P0212R1).
There are large code bases that don't excersize non-portable compiler features
like attributes. One such example is libresiprocate, which has quite a few
flags like the one I described in public headers. This is what actually led to
this bug report.
Also, I'll add that the warning cannot be silenced with a #pragma, so I can't,
for example, disable it for libresiprocate headers and leave it enabled for my
code.