On Wed, May 23, 2018 at 10:25 PM, Gleb Smirnoff <gleb...@freebsd.org> wrote: > On Wed, May 23, 2018 at 10:13:25PM -0700, Matthew Macy wrote: > M> On Wed, May 23, 2018 at 10:07 PM, Gleb Smirnoff <gleb...@freebsd.org> > wrote: > M> > Can you please explain the bug supposed to be fixed by r333860 QUESTION > MARK > M> > M> Did I say it fixed a bug? Or are you saying we should just turn off > M> compiler warnings because Gleb Smirnoff knows better? > > You just did say "Warnings find bugs PERIOD." This implicitly claimed > that shutting this one fixed a bug. > > Indeed, I am saying that in this particular case Gleb Smirnoff knows > better than gcc8 does. However, I'm not saying to turn off compiler warnings. > Never said that. I am saying (several times already) not to insert redundant > code to shut up a warning that is false.
I'm not saying you're right or wrong. On initial inspection it appeared uninitialized. I may be wrong. I never asserted that you were wrong. What I'm trying to understand is what your desired policy with respect to warnings is. If the author knows that a warning is false he should a) Disable that warning for the entire build because it is wrong in one case? b) Edit the Makefile to disable the warning for that file? c) Leave the warning enabled and just permit a noisy build where the warning potentially drowns out real issues? Right now you're discussing a single line in a single file when in fact this is a kernel wide policy issue. All three of these choices seem less desirable than selectively placating the compiler as I have en masse for much of the tree. -M _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"