Wireshark-dev: [Wireshark-dev] Prevent compiler warnings by using "stop on warnings"/"treat war
From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 20 Mar 2007 03:04:49 +0100
Hi List!

In my experience having a compiler warning free code is a good way to prevent very subtle bugs and would also be a good addition to the programs security - and BTW more pleasant to work with ;-)

You will often hear the following excuse on this topic: "but you cannot write code which won't produce warnings on all those compilers out there". While there are cases where this is true (which has to be handled individually), it's much more often a sign of lazy / ignorant / unskilled developers IMHO.

Unfortunately, we're currently having a clear trend to get more and more compiler warnings instead of less. Years ago, I've taken the work to remove warnings of the Win32 build to about 10, today we're having hundreds again :-(

While I would be willing to remove code warnings for Win32, I first thought about how to prevent new warnings to rush in - otherwise any work on this topic would be annoying by seeing new warnings rushing in shortly.

In my experience, preventing yourself to add new warnings to the WS is currently difficult because of the multi platform support. Even if you provide code that doesn't produce any warnings on "your" working platform, you won't simply notice any new warnings on other platforms (unless you take a look at the buildbot logs) - and compiling on multiple platforms all by yourself is not on option for most of the developers IMO. In the end this is what the buildbot is for.


So here comes the buildbot into the scene. If we would use a compiler option like "stop on warnings" (or "treat warnings as errors" or alike), it would become at least much more obvious if new warnings were added - the buildbot will get "red". This will also make the time when a warning is noticed much nearer to the time the code was added/changed - currently fixing a warning once added is often done much later than it was introduced (making the fix unnecessarily difficult).


Simply add such a compiler option to the current code state (with it's hundreds of current warnings) would make the buildbot "red" on all platforms for a very long time - which is probably not a good idea.

An incremental way to introduce this could be:

a) cleanup the warnings for a specific submodule (e.g. wiretap) and platform (e.g. Win32) b) set the compiler option for this submodule only to get a "barrier" for new warnings to rush in
c) continue with a) for next submodule :-)

As usual, this is my "Win32 point of view". I'm pretty sure the above is possible to do for the Win32 platform. I'm not sure if it's possible with the automake foo for the different unix/linux platform builds ...


In effect, the above is to introduce the new coding policy "write warning free code" and a way to "enforce" this.

So what's the opinion about this way to improve the Wireshark code base?
Are we willing to produce only warning free code and fixing warnings that appear on the buildbot? While I would take a look on the Win32 warnings, are the unix/linux developers willing to spend some time to remove warnings that don't appear on Win32 (or would this be a "Win32 only" show)?

Regards, ULFL