3 ms·
We use -Wall and -Wextra, and fixed basically all our warnings. Now everyone writes virtually warning-free code (that is, any warning is fixed before committing
by archi42 7y ago
We use -Wall and -Wextra, and fixed basically all our warnings. Now everyone writes virtually warning-free code (that is, any warning is fixed before committing). And I don't feel limited in what I can do.
We could roll -Werror for most packages (I think we have a few packages, e.g. 3rd party libs, which emit warnings), but only use error=format and error=format-extra-args.
To be fair, we disable these warnings (-Wno-...): unknown-pragmas, long-long, register, unused-command-line-argument.
- seba_dos1 7y agoI just keep my codebase warning free and check it in CI. No need for -Werror on package level, users don't need to deal with random breakage from a false-positive warning.
- archi42 7y agoIf you don't control the build env (e.g. FOSS work), then of course relying on -Werror might yield unnecessary trouble.
- marcosdumay 7y agoYou never completely control your build env. You are always relying on 3rd parties for some extent. That may not look relevant in short periods of time, but there are large odds that somebody will be biten by your choice of using -Werror 5 or 10 years down the road.
- archi42 7y agoI would not sign that claim as a general truth. It's true under some assumptions, but then, well, just disable -Werror in 5 to 10 years? It's not like THAT is a breaking change. OTOH 5 to 10 years is a good way to accumulate plenty of warnings (assuming a lack of development discipline), which at some point makes it easy to miss that one critical warning that should really be fixed. Maybe I should mention the worst case for an error in the code I write is "people die" (static analysis of safety critical stuff), so that's a good motivation to have no warnings ;-)