RFC: Avoiding #warning (C/C++ preprocessor extension)

Frans Englich frans.englich at telia.com
Tue Nov 1 16:04:21 GMT 2005


On Tuesday 01 November 2005 13:34, Mirko Boehm wrote:
> On Monday 31 October 2005 23:15, Nicolas Goutte wrote:
> > > I would
> > > say that no release tarball should contain -Werror.  It may be useful
> > > during development but it would be unnecessarily painful for release.
> >
> > ... so you cannot even have it in development, except if everybody would
> > use the same gcc version.
>
> Why not? It can be used as a standard during development, and removed
> before the release.
>
> On the other hand, I do not see the point. Removing annoying "unused
> parameter" warnings should be a habit, no need to make the compiler barf at
> the first point where it encounters it. What is wrong with letting make
> finish the compile, and then removing all the warnings at once?

If you ask me: absolutely nothing. The problem, as I see it, is that no one do 
that final check. Old warnings stays for ages -- "someone else is supposed to 
fix that". Thus, in order to have it done at all, one have put it directly in 
front of developers such that untidy code can't end up in the repository in 
the first place.

Applying the hypothetical "-Werror at development but not release time" would 
no doubt make the code more tidy. Apparently, that people would have to fix 
warnings "now" instead of "later" is too much work, and not worth the 
improvement it in general would mean.

Quoting: "Removing annoying 'unused parameter' warnings should be a habit". I 
think a good habit is doing it right now, when it is introduced. I think "I 
will do it later"(tm) is a vague habit.

Personally, I've used -Werror & co for some time, and I find it practical. It 
makes me think about the code I'm writing right now -- "Why is the algorithm 
I just wrote not using this parameter?", "What did I do wrong since the code 
path can end without return value?" -- and after I've fixed it, I simply know 
the code is pretty and that it's done and won't be forgotten because it 
cannot be.

I don't think one want warnings fixed by a big zombie commit months after the 
code was written, by someone other than the original author. One wants it 
fixed by the original author, and while intimate understanding of the code is 
still there. Perhaps the parameter actually should be used, and that a bug is 
hiding.

(That's not the same as saying -Werror comes without trouble, as evident in 
this thread. Coolo outlined the trouble when doing large refactorings, and 
different compiler versions warn on different things, to name a few examples. 
But those are other issues.)


Cheers,

		Frans




More information about the kde-core-devel mailing list