Wireshark-dev: Re: [Wireshark-dev] Prevent compiler warnings by using "stop on warnings"/"treat
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.
