severity 625357 normal
retitle 625357 gcc -Wunused-but-set-variable should not be implied by -Wall (?)
tags 625357 = upstream moreinfo
quit
Hi again,
Steve McIntyre wrote:
> I'll remove the -Werror to stop gcc breaking the build here, but I
> definitely believe that gcc is doing the wrong thing here.
> Technically, yes - the variables are set but unused. However, this is
> a far higher level of pedantry than is warranted for -Wall. The code
> being complained about is perfectly valid, typical of the defensive
> programming pattern of "initialise all variables".
To clarify: here's a demo of the behavior of gcc-4.4.
$ program_one='int main(void) { int x = 5; return 0; }'
$ program_two='int main(void) { int x; x = 5; return 0; }'
$ echo "$program_one" | gcc-4.4 -Wall -x c -
<stdin>: In function ‘main’:
<stdin>:1: warning: unused variable ‘x’
$ echo "$program_two" | gcc-4.4 -Wall -x c -
So imho gcc before v4.6 is just fundamentally confused. Which means
there are a number of ways one could go with this. Do you mean:
A. Unused variables are not a big deal, and they belong in -Wextra,
not -Wall.
B. New warnings are a pain in the neck and should go in -Wextra
during a transition period.
C. The idiom
ssize_t unused;
/*
* Yes, there might be an error, dear gcc -D_FORTIFY_SOURCE,
* but we want to ignore it.
*/
unused = write(...);
in place of, say,
/* loop on partial writes and EINTR */
xwrite(...);
is good style and the -Wunused-but-set-variable warning is
fundamentally misguided.
D. The idiom
int x;
int y;
... ordinary code ...
#if SOMETIMES
... code to set and use x ...
#endif
in place of
#if SOMETIMES
int x;
#endif
int y;
... ordinary code ...
#if SOMETIMES
... code to set and use x ...
#endif
or
int y;
... ordinary code ...
#if SOMETIMES
{
int x;
... code to set and use x ...
}
#endif
is good style and the longstanding -Wunused-variable warning is
fundamentally misguided.
D. Something else?
Sorry for the lack of clarity before.
Jonathan
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110602181659.GA466@elie
