Re: compiler warnings, -Werror, etc.

[Martyn Russell <martyn lanedo com>]

On 28/07/12 13:58, Benjamin Otte wrote:
> Colin Walters <walters <at> verbum.org> writes:

Colin, I am in favour of what you suggested. I think it makes a lot of 
sense.

> > First, compiler warnings range widely in how important they are.  Some
> > of them, like -Wmissing-prototypes, are pretty much always indicative of
> > a serious problem in your code.  Others like -Wmaybe-uninitialzed are
> > actually *heuristics* - the GCC manual clearly states that GCC may in
> > fact be wrong, and that one even has "maybe" in the name.
> I think the general consensus is that code that triggers these warnings is bad
> code. The job of source code is not just to ensure that the compiler generates
> correct output, but also to ensure that somebody who modifies that source code
> later will still make the compiler generate correct output.
>
> Second, I don't think you are the right person to determine which warnings are
> or are not important. Apparently the GCC developers think otherwise and I
> frankly trust them more than I trust you. (And the maybe in the name is because
> the variabe is "maybe uninitialized", not because gcc thinks it has maybe found
> an uninitialized variable - in contrast to -Wuninitialized.)

I do not want to start a flame here, so this will be all I say on this 
matter; but I think it's comments like this that drives people away from 
open source projects. Please give constructive feedback, otherwise 
you're just wasting time and upsetting people.

It's good to question things.

> > So I think what Dan has is more the Right Thing - make the compiler
> > warnings that you should *never* hit into explicit errors.  That
> > establishes a minimum baseline.  Maintainers should feel free to make
> > some other things into errors as they wish (-Werror=unused-but-set), but
> > please don't use -Werror=deprecated-declarations or
> > -Werror=mabe-uninitialized.
> I work in a module where people do not want to use -Werror. This leads to
> regular commits with warnings and nobody fixes them but me. So I assume that
> in projects where I am not a member these warnings often go unfixed for a long

Conversely, you're also working on a module which doesn't just build on 
one platform. Warnings easily occur on such projects.

> time. So what essentially happens is that we move QA from compile-time to
> run-time. We ignore the warnings about brokenness that the compiler gives us
> for free and instead let users find those bugs the hard way. Isn't that a bad
> way to do development?
> Sure, for a packager who just wants to compile stuff and whose work doesn't
> involve makig sure things are bugfree it's a nuisance that we make him fix it.
> But wouldn't we rather have them get it fixed than users who just lost their
> data?

Vala generates warnings sometimes. I think the seriousness of these are 
on a sliding scale, as such, I don't think it's wise to categorise all 
warnings as critical or harmless generally speaking either.

I for one hate to see any warnings in my projects and I don't mind 
cleaning them up. I quite enjoy it in fact. I don't think this is a 
maintenance burden either if you're getting the right balance of patch 
review on a project.

--
Regards,
Martyn

Founder and CEO of Lanedo GmbH.