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.
Yes, it might mean that an update to a new gcc version means required
changes. But guess what? Whenever a warning pops up there is likely a
good reason for it and it is worthwhile spending time on it. Just like
all these signed vs unsigned warnings in gcc 4. They almost all the
time warrant looking at the code.
Nothing stops you from doing internal builds with -Werror and then
fixing all the warnings before you make a release.
However, when you ship software that won't compile, your end users are
either going to remove -Werror and rebuild or they're going to switch to
something that works out-of-the-metaphorical-box. You've gained nothing.
Nicholas Miell <nmiell(a)comcast.net>