On Sat, 2005-08-06 at 16:55 -0700, Ulrich Drepper wrote:
Nicholas Miell wrote:
> I'd argue that any upstream package which includes -Werror by default is
> broken, considering how often gcc warnings change.
And I argue that we apparently must come to a state where -Werror is
enabled automatically. The current state, aggravated by adding -Wall,
is that warnings are ignored. The result: bugs the compiler finds are
no fixed. I even found one case where the _FORTIFY_SOURCE magic found a
buffer overflow and the maintainer hasn't seen it.
It is crucial that packages are changed to have zero warnings.
Otherwise these bugs remain unnoticed since people think warnings are OK
and don't care. The "apparent" part is that using -Werror is the only
way to do this. Without enforcement people _think_ there are more
important things to do than fixing warnings.
-Werror here seems like an unnecessarily blunt tool; there are
plenty of warnings (unused variable warnings for example) that *do not*
typically indicate real breakage, and having to patch around them
in spec files would be wasting the package maintainer's time.
Remember, on some packages we have only very small influence on the
upstream maintainers and its not always easy to convince a maintainer
to work around a false-positive warning, so we could have very
large patch sets for some packages to suppress warnings.
On the other hand, there are some warnings that almost always indicate
serious problems (the warning you get when passing an int * to something
that takes a long * on a 64-bit machine, for example.)
We should easily be able to scan build logs for warnings with either
a white-list or a black-list and fail builds based on that.
Regards,
Owen