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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
