Inline comments... On 3/20/07, Martin Mathieson <[EMAIL PROTECTED]> wrote: > > Currently, you don't tend to even notice new warnings that you introduce > > on your own platform, as they get lost in the general compilation noise.
> Part of the problem (when working from the command-line at least) is > how much output is generated, and how far you'd need to scroll back to > see the compilation of the file you've just changed. For speed, I > spend much of the time only compiling the one file, e.g. I'll run > 'make epan/dissectors/packet-whatever.lo' until my changes compile. > This makes my affect on the number of warnings pretty obvious. Which I believe is what we should all do. I been following a policy myself is that for every file I modify I remove all the warnings I get (well I leave there those for static functions not used and some about signedness of strings). If at least the "committers" take an approach of squelching warnings one file at a time, while we work on that file, little by little we can get rid of most (if not all) of them... I do not think we should deeply involve ourselves on a project of fixing warnings as a task on its own... I think our time is better used by either adding new features or fixing factual bugs, and while at it remove the warnings from the files we edit/patch. > > Incidentally, if anyone knows the right knob to stop gcc accepting > > variable declarations in the middle of a block of code, it really needs > > turning on. I manage to mess this up almost every time I submit a patch... > I think -Wdeclaration-after-statement is what you need. I think that's what I need as well! -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
