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++/71402] -Wunused-variable warnings ignore initialization side effects


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.

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