Re: Linux 2.6.19-rc4

[Willy Tarreau <w@1wt.eu>]

On Tue, Oct 31, 2006 at 03:53:00PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > > At some point we should get rid of all the "politeness" warnings, just
> > > > because they can end up hiding the _real_ ones.
> > >
> > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > > uninitialized variable crap from gcc 4.x ?
> > 
> > What would be useful in the short term is a tool that shows only the
> > new warnings that didn't exist in the last point release.
> 
> Harder to do than you might think - it has to deal with the fact that
> 2.6.N might have a warning about 'used unintialized on line 430', and
> in 2.6.N+1 you get two warnings, one on line 420 and one on 440.  Which
> one is new and which one just moved 10 lines up or down?  Or did a patch
> fix the one on 430 and add 2 new ones?

Not necessarily harder. On a related topic, I maintain an own tree with
about 60-100 patches, added to about as much for the glue to resolve
conflicts. When I apply them in sequence, I get lots of rejects and
fuzzy matches. Initially, it was very hard to know which ones were
expected (and solved) and which ones were new. So I archived the stderr
of the "patch" command in a file named "apply.log". It just show the
patch name and its output if any. Now, when I make a new version, I don't
worry about the warnings or errors, I just diff the new result with the
previous one and quickly detect the patches which conflicts, or even
subtle changes such as fuzzy matches, or "2 hunks failed" instead of
"1 hunk failed".

Since diff's algorithm is very efficient at resynchronizing, you most
often detect only a few changes. From experience, the fact that some
warnings change from line 420 to 440 is very easy to process because
at a glance because you quickly detect that the line is not far away
from the old one, and the warning is exactly the same. So you don't
worry. When you have a doubt, you simply check the code.

The only situation I can imagine which would cause large amounts of
warnings is the ones caused by includes which will propagate to
all files.

I've not tried Al's remapper, but considering how he hates useless
warnings and hidden bugs, I can imagine he has attacked the problem
on the right side ;-)

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/