GCC warnings for unused global variables

[Marc Espie]

On Fri, May 02, 2003 at 02:43:53PM +0200, Gabriel Dos Reis wrote:
> Marc Espie <espie@quatramaran.ens.fr> writes:
> 
> | In article <20030430083713.GU4016@paradies.suse.de> you write:
> | >* Alexander Kabaev (ak03@gte.com) [20030429 22:57]:
> | >
> | >> #ifndef lint
> | >> static const char rcsid[] =
> | >>   "$Id: src/dir/file.c 1.12 1999/08/27 23:45:12 me Exp$";
> | >> #endif /* not lint */
> | >
> | >Why not just use __attribute__((__unused__))?
> | >
> | >Philipp
> | 
> | Because it's a gcc extension, so writing portable code that
> | uses it will require some more machinery, hence more clutter.
> 
> You cannot argue at the same time for portable code and having or not
> having diagnostics, which are by definition, implementation defined.
> At the very point you start elaborating about diagnostics, you
> accept implementation defined semantics and constructs, hence "writing
> portable code" cannot be the decisive argument.  It ought to be
> something else. 

Let's drop the `standardese cap' for a minute.

I don't care at all about how the standard phrases it, how it is
implementation dependent.

However, I care deeply about current practices, preferably best.

There are good projects that use -Wall -Werror.   Each warning you add to
-Wall can cause grief. Some warnings are perfectly justified. For instance,
deprecated constructs should warn.

But some warnings occur naturally in a project. Would you add -Wshadow to
the default set of warnings in -Wall ?   See, this is exactly the same.
For years now, people have embedded identifying strings in code using
static const char *, and now, you are actually breaking this construct.

Yes, this is implementation-dependent. So what ?
You will cause people to drop -Wall -Werror, or to fix a lot of lines of
code that are not even wrong in the first place. See, the point is that
those lines are perfectly correct in the first place.

> FWIW, I'm not convinced by the "it is a regression" argument, that is
> streching the notion of "regression".  If we want to take that route,
> then we should stop fixing bugs in the compilers because fixing bugs
> means removing (or adding) something that was (or weren't) there before.

No, this is a regression. There is a measure called `quality of
implementation'.  In a software engineering setting, warning against a
perfectly natural, usual idiom of the language is a regression in the
quality of the diagnostics.  It will let big projects that use -Wall
-Werror fail (and cause time lost fixing that regression, because you know
quite well that any significant project will have a *BIG* Makefile
infrastructure, part of it legacy, and that finding the correct
Makefile/shell/m4/whatever fragment that generates the actuall -Wall
-Werror can be hell to find). 

Now, if you were to emit that diagnostic in
every case, except for `const char *', I wouldn't care.

And, I'm sorry Gaby, but be assured that whatever rational explanations 
for that warning you can find as language lawyer count as exactly 
ZERO, ZILCH, NADA in some programming circles I know (specifically,
the people who don't have any interest in how the C language is designed,
but just want a compiler that works).  Believe me, I'm talking from
personal experience (and this case is completely plain cut compared to some
of the less valid complaints I've heard).

Specifically, to reiterate, because this is a valid construct. And because
it is very simple to put machinery that WON'T warn in that specific case.
Because it is very simple to dissociate that warning from -Wall. And
because that construct did use to work JUST FINE up until the previous
release.