Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Dec 2011 17:33:31 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r228668 - head/usr.bin/netstat
Message-ID:  <4EEE15DB.6060604@FreeBSD.org>
In-Reply-To: <20111218014144.GB20867@zim.MIT.EDU>
References:  <201112172232.pBHMW1Bd079555@svn.freebsd.org> <4EED18B5.8000907@FreeBSD.org> <20111218013905.GA20867@zim.MIT.EDU> <20111218014144.GB20867@zim.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2011-12-18 02:41, David Schultz wrote:
... 
> Sorry, one more: In less(1), you cast away a bunch of const qualifiers
> to fix some warnings, but that seems like a step in the wrong
> direction.  The warnings were complaining about genuinely bad code.
> Disabling the warnings with casts doesn't make less(1) any better;
> instead, it guarantees that nobody will ever fix the code.

Yes, I did it purposefully this way.  Constifying the whole program
would have much more impact, and increase the probability of a bug
sneaking in.  That said, if anybody knows if the less maintainer (Mark
Nudelman?) is responsive, I have no problem doing a proper const
poisoning, and submitting it to him for review.


> Perhaps the larger question is whether it makes sense to fix non-bugs
> in contributed code at all.  What do we get out of it?  Maybe if the
> contrib software is poorly maintained we'll find a bunch of real bugs
> that won't be addressed upstream.  Otherwise, the diffs are only creating
> headaches for whoever imports the next version.

The criterion I use for fixing warnings is rather simple: if the contrib
software is compiled with -Werror, then apparently we (or at least some
of us :) are interested in the warnings, and they should be fixed.  If
we are not interested in the warnings, we should just turn off -Werror.

Of course, if warnings point to a real problem, and upstream for the
contrib software still exists, we should strive for submitting them, and
getting them back through imports.  That can take a very long time,
however, and meanwhile the warnings still block building world with
-Werror.  Thus, in some cases, it is better to fix them now, and just
merge the fixes during import.  If upstream accepts our fixes verbatim,
they should not conflict anyway.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EEE15DB.6060604>