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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
