the point is what kind of warnings can be cleaned up: to fix "pointer arguments differ in signedness" for example would be a waste of time, as they are caused by guint8* used instaed of gchar* on those systems (most) that treat char as an unsigned.
But in order to follow that policy you'll have to fill the code with "(void*)" casts (which is ugly) beacuse if you simply work on a system that treats char as unsigned you can guess what would happen. BTW a more tolerant policy of no *more* warnings (than those we already have) would be implementable by something like: cp warnings last_warnings make 2>&1 >warnings diff -u warnings last_warnings | grep '^+' || warn_and_blame_last_commiter On 3/20/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > 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 > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
