Re: RFC: should we use -Werror? (& sample patch to do it)

["Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>]

 > From: Zack Weinberg <zack@codesourcery.com>
 > 
 > On Wed, Sep 05, 2001 at 03:51:59PM -0400, Kaveh R. Ghazi wrote:
 > >  > These are not warnings we want to ignore, either.  Those strings
 > >  > really are too long to be safe.
 > >  > Please, can we stop trying to paper over the problems and _fix_ them?
 > > 
 > > Well that's a separate question.  I don't know of any way short of
 > > rewriting the whole specs stuff that Neil was suggesting.  I'm not
 > > generally in favor of papering over things, but at the same time I
 > > don't think -Werror should necessarily bottleneck on a specs
 > > implementation rewrite if a simple workaround is available and the
 > > long term solution is on someone else's todo list.
 > 
 > You and I seem to be coming at this from different angles.  I am not
 > yet convinced that -Werror is actually a good idea, even if we *did*
 > have zero warnings across all targets, which we don't.  I would like
 > to discuss how we can get to zero warnings, instead of how we should
 > enforce its staying that way once we do get there.

Dicussing whether -Werror is a good idea is part of why I posted an
RFC.  I'm not wedded to -Werror, but I would like some way of at least
not getting more warning regressions every week.  I previously
suggested incorporating the output from contrib/warn_summary into the
regression tester.  But not having seen that happen (and not having
the time myself) I thought we could take another approach.


 > The reason I'm not convinced that -Werror would be a good idea even
 > after we get to zero warnings, is that the existing set of warnings
 > have been around for a very long time because they're both harmless
 > and intractable.  (Harmless, in the sense that I am fairly sure the
 > code is in all cases correct, just pulling dubious tricks.)  I feel
 > it's likely that, even if we do solve all of them, we will get more
 > code in the same category - causes harmless, intractable warnings -
 > and then there will be much finger-pointing and raging and gnashing
 > of teeth, should we enforce zero warnings with -Werror.
 > 
 > I'd like to make a comparison to the argument we had over whether
 > patches that exposed bugs elsewhere, should be reverted.  All the
 > warnings in combine.c happen because someone decided mode_bitsize
 > should be unsigned.  They were probably right.  With -Werror, the
 > patch that made it unsigned would have broken bootstrap, and then
 > we would have had an endless unproductive flamewar about it.
 > zw

No with -Werror, the patch wouldn't have been accepted in the first
place because the submitter couldn't have said they were able to
bootstrap with it.  This may have encouraged them to fix the new
warnings too along with their patch submission.  Think of it like
ENABLE_CHECKING failures.  Previously we would have allowed in a patch
which quietly introduced bugs.  Now with ENABLE_CHECKING on by
default, you can't bootstrap your patch if it doesn't pass these
internal consistency checks.  Using -Werror would do an analogous
thing, encourage everyone to not introduce new warnings.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions