Wireshark · Wireshark-dev: Re: [Wireshark-dev] Add /analyze to the Windows based build?

[Ulf Lamping <ulf.lamping@xxxxxx>]

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