https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #25 from Mark Wielaard <mark at gcc dot gnu.org> --- (In reply to Josh Triplett from comment #23) > (In reply to Mark Wielaard from comment #21) > > Although in C a static const is not really like a #define > > Why not? Many C projects try to avoid the preprocessor as much as possible. The difference is that a static const defines variable storage in C. > > I suspect that > > there are cases where they are used as such in header files. If that is the > > major reason for why there are people opposed to the warning then what we > > could do is hide such (non-)usage of static const variables from header > > files behind -Wextra and only explicitly warn for static const variable > > defined (and then not used) in the main file. > > Please don't attach this to -Wextra; instead, please consider making it a > -Wconst-unused-variable=2 or similar. Otherwise, projects using static > const values in header files would get a massive pile of additional > warnings, typically all false positives. Do you mean split it into -Wconst-unused-variable=1 for main compile unit that is part of -Wunused-variable and a -Wconst-unused-variable=2 that is activated by -Wextra? > In a main file, this makes sense and likely has relatively few false > positives; the most common false positive would involve defining something > only used in ifdef'd code, and even then tagging it with > __attribute__((unused)) (Linux's __maybe_unused) seems correct. > > However, in a header file, any use of static const to define constants for a > project will almost certainly get this warning, unless every single user of > that header file (directly or indirectly) uses every constant (or unless the > header itself does). Silently throwing away the unused constants seems like > the right thing to do there. I am trying to find out if there are any false positives, or warnings that people really find annoying and cannot easily fix. If so, it might make sense to split the warning. But at least from the comments in this bug report it is unclear to me. Maybe it is obvious to others. But see comment #21 for the 3 ways to read the comments in this bug report. What is clear is that there is no consensus. Maybe that is enough reason to do the split anyway. But it would be nice to have some actual examples in actual code that everybody agrees is not OK to warn about.
