Wireshark-dev: Re: [Wireshark-dev] Prevent compiler warnings by using "stop on warnings"/"treat

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 19 Mar 2007 19:59:51 -0700

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.