I agree that all warnings should be generally be turned on and snuffed out (Though there are a few innocuous warnings that I turn off sometimes), however I woul

I agree that all warnings should be generally be turned on and snuffed out (Though there are a few innocuous warnings that I turn off sometimes), however I wouldn't recommend the usage of -Werror to force that unless it's only enabled for dev builds. Warnings are generally impossible to fully predict: different compilers can give different warnings - from warnings enabled by default, warnings changed between versions, and warnings that differ between compilers. And of course, there's no wrong way for the compiler to do it because what to warn about is subjective in the first place. That can become really annoying for an end user looking to just compile and run your software, not debug why it fails to build because their setup outputs a warning somewhere that may not even be an error. And turning off -Werror tends to then require delving into Makefiles (or whatever other build system they chose to use), and at that point most people are probably just not going to bother and call it broken. Again, I'm not saying you shouldn't attempt to snuff out and find every warning that you can, but you shouldn't have your default build rely on compiling with no warnings. There's just too many variables uncounted for to expect your software to compile without warnings in every possible configuration. I also agree 100% with running test suites through valgrind - I do that as well and it's a very good way to guard against memory leaks being introduced (Of course, good structure and design techniques are always the best defense, but there's nothing wrong with a good check that things are doing good).