On 09/15/2015 11:20 AM, Steve Ellcey wrote:
On Tue, 2015-09-15 at 19:10 +0200, Jakub Jelinek wrote:
On Tue, Sep 15, 2015 at 10:02:15AM -0700, Steve Ellcey wrote:
I am not sure I like this change. It broke the GLIBC build for me on
MIPS. Basically GLIBC has a header file with initialized static
constant globals (sysdeps/ieee754/dbl-64/atnat2.h contains tqpi1 and
qpi1) and that header file is included in multiple .c files like
Multiple? All I can see is e_atan2.c including that header file, nothing
else.
Whoops, bad assumption on my part. I thought it must be included
somewhere else, otherwise why put it in a header.
sysdeps/ieee754/dbl-64/e_atan2.c that use some, but not all, of those
static constant variables. But between the various .c files all of the
globals are used somewhere, just not in every individual .c file. This
seems like a perfectly reasonable use of static globals and header files
that should not be identified as a warning.
I disagree. While const vars are special in C++, it is really like
any other variable in C, so the warning is IMHO appropriate.
Jakub
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?
Martin
