Re: compiler warnings, -Werror, etc.

[Benjamin Otte <otte gnome org>]

12345678901234567890123456789012345678901234567890123456789012345678901234567890

Colin Walters <walters <at> verbum.org> writes:

> 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.)

> 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
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?

> what actually ends up happening
> is your code only compiles on a *particular version* of gcc.  That just
> doesn't work in a distributed project like GNOME, where various bits get
> reused by different projects and products on different schedules etc.
>
I think what we should do is restrict the list of supported compilers - in
particular for git checkouts, but I'd argue we should require gcc >= 4.4 for
GNOME compilation. We do the same thing with all the other stuff we depend on
(autoconf, make, libraries, you name it) so why are we so nice on the 
compiler front?

Benjamin