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. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
