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>