[PATCH] PR28901 -Wunused-variable ignores unused const initialised variables

[Mark Wielaard]

On Wed, 2015-09-23 at 12:25 -0600, Jeff Law wrote:
> On 09/18/2015 08:29 PM, Martin Sebor wrote:
> >> I guess it is not the 'const' I think should be handled special but the
> >> 'static'.  Having unused static variables (const or not) declared in a
> >> header file but unused seems reasonable since the header file may be
> >> included in multiple .c files each of which uses a subset of the static
> >> variables.
> >
> > I tend to agree. I suppose diagnosing unused non-const static
> > definitions might be helpful but I can't think of a good reason
> > to diagnose unused initialized static consts in C. Especially
> > since they're not diagnosed in C++.
> >
> > Would diagnosing them in source files while avoiding the warning
> > for static const definitions in headers be an acceptable compromise?
> It's probably worth a try.

I am a little concerned that would hide some real issues. In the case of
glibc the header files were actually only used by one main file, so the
variables were indeed unused and needed to be investigated why they were
there in the first place. In the case of wine the issue was that the
header file contained non-idiomatic and somewhat unreadable C constructs
that could easily be replaced by more readable defines for 16bit char
string constants.

Even if there are such constructs in header files and they aren't
actually bugs or people are unwilling to fix the issue with something
that is more idiomatic C then there are various ways to suppress the
warning. Either just don't use -Wunused-variable or add
-Wno-unused-const-variable. Add an explicit __attribute__((used)) or
just add a #pragma GCC system_header to the .h file.

If we are concerned that this generates warnings that aren't easy to
avoid then we might want to add that particular check behind -Wextra.
But is that really necessary? I am not against implementing an extra
warning exception/flag if it really is necessary. But it does introduce
more complexity and makes the warning less consistent. So what would be
a good way to find out one way or another whether the extra complexity
is needed?

Cheers,

Mark