Inline comments...
On 3/20/07, Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx> 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
