Re: compiler warnings, -Werror, etc.

On 28/07/12 13:58, Benjamin Otte wrote:
Colin Walters <walters <at>> 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

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

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.


Founder and CEO of Lanedo GmbH.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]