Jeff Law <l...@redhat.com> writes:

> I think (as always) we need to find a balance between throwing
> everything *we* find valuable in -Wall and avoiding all changes to
> accommodate users on the other end of the spectrum.  With that in mind
> I'd ask Ian to chime in and say something about the # of warnings we
> found in our own codebase vs how many of those warnings represented
> real bugs vs false positives.

I already answered that one upstream.  There were three occurrences in
gcc proper which I fixed.  They were:

http://gcc.gnu.org/viewcvs/trunk/gcc/df-problems.c?r1=148512&r2=148511&pathrev=148512

http://gcc.gnu.org/viewcvs/trunk/gcc/gcov.c?r1=148512&r2=148511&pathrev=148512

http://gcc.gnu.org/viewcvs/trunk/gcc/cp/parser.c?r1=148512&r2=148511&pathrev=148512

I've seen two other problems in code that we compile without -Werror:
libiberty/regex.c and gcc/unwind-dw2-fde-glibc.c.

In none of these cases would the code execute incorrectly.

In df-problems the problem amounted to missing braces around a switch.
In gcov.c an error condition had a goto back to an earlier error
condition.  The code in cp/parser.c I would describe as spaghetti code
which ought to use a helper function instead.  The code in
libiberty/regex.c seems to have something to do with backtracing; it
looks pretty ugly (it's goto restore_best_regs on line 7476).  The code
in unwind-dw2-fde-glibc.c, the only goto in the file, skips over a
variable declaration in the middle of a function.

This sort of code is always going to be a little bit dubious simply
because it can only happen with a goto into the middle of a function
somewhere, or a switch statement written in a peculiar way.  That said,
I'm perfectly amenable to moving the new warning to -Wextra or just
turning it on only with -Wc++-compat.  I don't personally care that
much, actually.

Ian

Reply via email to