Wireshark-dev: Re: [Wireshark-dev] Add /analyze to the Windows based build?
Peter Johansson schrieb:
A while ago, Ulf (if I remember correctly) managed to get us involved
in getting the sources warning free (treat warnings as errors).
As I have just been made aware of that the world is not a perfect
place (again) where the VC2005 compiler will not produce warnings
where other compilers will, I went through the options list for the
VC2005 compiler to see if there is something there that might make it
a bit more picky.
I found the option /analyze which, when used, shows quite a lot of
compilation "warnings" that should be of interest. I enabled it on the
files in epan\dissectors, the output has been attached for reference.
I had to use /analyze together with :WX- (/analyze:WX-) which will
make it warn but not allow the WX option to stop the build based on
what the analyze pass finds. It warns for instance about "Unsing
uninitialized memory", "Incorrect operator", "Unreachable code" and
potential operator precedence problems.
Would it be a good idea to add the /analyze option to Windows based
builds perhaps (at least when compiling with the VC2005 compiler)? I
am unaware of whether this option is available on any of the other VC
compilers.
That's basically the old question of "which compiler warnings should I
turn on"?
I'm unsure if we should use this option and I also don't know if MSVC 6
or which versions inbetween supports this option.
My personal feeling is that all warnings should stop the compilation,
otherwise you'll get into the same problem as we had before - an ever
increasing number of warnings that garbles the screen output and no one
attempts to fix them.
So if we want to use the /analyze switch, all warnings should be fixed
that appear then and to my experience the "unreachable code" warning
*will* give you real headaches when used on different compilers.
In the end, you will always have different warnings on different
compilers, so raising the number of warnings on MSVC won't solve the
problem completely, but probably ends up the raising on "the gcc side"
to also detect warnings that MSVC now finds ...
I just don't know if /analyze will find "real problems" that need to be
fixed or only things that should be fixed in an "ideal world" but never
causes real problems. Fixing warnings to only fix the warnings is
probably mood ...
Regards, ULFL
