svn commit: r333860 - head/sys/kern

[Matthew Macy]

On Wed, May 23, 2018 at 10:25 PM, Gleb Smirnoff <glebius at 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 <glebius at 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