On Mar 19, 2007, at 7:04 PM, Ulf Lamping wrote: > 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.
The main reason for warnings you can't eliminate, I suspect, are crufty vendor #include headers. At least some versions of Solaris have, as I remember, crappy old X11 headers that don't have function prototypes by default, hence the hack to turn them on in configure.in, and some don't declare a return type even with -DFUNCPROTO=15. If there are vendor headers that can't be worked around in a fashion such as that, some platforms might have a problem. If all else fails, we could leave the "stop on warnings" option off on that platform. Another issue is that a lot of code is automatically generated; I suspect both asn2wrs and the PIDL generator need to be fixed to decorate function arguments with _U_, or to leave the arguments out, or to generate code that uses them. For some reason, a lot of asn2wrs-generated files appear to generate a bunch of unused functions; I don't know if that's an asn2wrs problem or a problem with the ASN.1 being processed. > 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? I think it's at least worth trying. _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
