We now test all the code through valgrind; a single memory leak will complain. There are also static analysis, and various other checks.
And BTW, you can't treat warnings as errors. Just try to fix the warnings we have and you might understand why it's not possible easily (might require API changes, compiler false-positive, deprecated warnings that can just be silenced, etc). Of course, you might be able to fix some easily, and the patches will likely be accepted (assuming they are correct).
Glad to here that more testing is done. The "warnings as errors" is controversial, but it's practice I like. Once your compile has hundreds of "safe" warnings flashing across the screen, you aren't going to notice the "real" warning caused by your latest change. Whereby if your code compiles cleanly and quietly, you'll definitely notice the new one. Defaulting to -Werror is just a way to enforce this convention.
You are absolutely right that not all the warnings are accurate, and that not all code should be changed to satisfy a every compiler. But I'm arguing that there is a long-term benefit to choosing a single compiler, and making the modifications necessary to allow this compiler to run without warnings, even if the behaviour is provably correct without doing so.
I'm pretty sure a project as widely used as FFmpeg can't just choose a single compiler (and you'd actually have to choose a single compiler version since for instance new versions of GCC can introduce new warnings).
On top of that, sometimes warnings come from parts of the code you don't control, like a scanner generated by flex.
I think it's better to have a strong policy of not introducing warnings and fixing them whenever a particular compiler is foud to emit them, but having -Werror in the default Makefile can quickly inundate the project's mailing list/IRC channel with "doesn't compile" complaints from people with exotic compilers.
Mosh has an optional ./configure --enable-compile-warnings=error flag that turns on -Werror. It's off by default for users who compile from source, but the Debian, Ubuntu and Fedora packaging uses it to prepare the binary package. We think this is a good compromise.
We might be agreeing. I'm not arguing for -Werror on by default for a project that is designed to be compiled from source by end users using their own compiler. I am arguing that a clean compile is valuable for developers. Yes, this may get down to choosing versions.
"Some people say that we should eliminate all warnings because benign warnings mask real warnings that might arise in future changes. This is true enough. But in reply, the developers observe that all warnings have already been fixed in the compilers used for SQLite development (various versions of GCC). Compiler warnings only arise from compilers that the developers do not use on a daily basis (Ex: MSVC)."
We now test all the code through valgrind; a single memory leak will complain. There are also static analysis, and various other checks.
And BTW, you can't treat warnings as errors. Just try to fix the warnings we have and you might understand why it's not possible easily (might require API changes, compiler false-positive, deprecated warnings that can just be silenced, etc). Of course, you might be able to fix some easily, and the patches will likely be accepted (assuming they are correct).