svn commit: r333860 - head/sys/kern

[Matthew Macy]

On Thu, May 24, 2018 at 8:58 AM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Thu, May 24, 2018 at 12:53 AM, Matthew Macy <mmacy at freebsd.org> wrote:
>>
>> On Wed, May 23, 2018 at 11:42 PM, Michael Tuexen
>> <Michael.Tuexen at macmic.franken.de> wrote:
>> >> On 24. May 2018, at 08:36, Matthew Macy <mmacy at freebsd.org> wrote:
>> >>
>> >> On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen
>> >> <Michael.Tuexen at macmic.franken.de> wrote:
>> >>>> On 24. May 2018, at 06:51, Matthew Macy <mmacy at freebsd.org> wrote:
>> >>>>
>> >>>> Warnings find bugs PERIOD. Although most are not useful, I've found
>> >>> Some warnings indicate bugs, some warnings are just wrong. If you
>> >>> have a "may be used uninitialized" warning being a false positive, you
>> >>> may silences the warning by just set it to zero in the declaration and
>> >>> you silence it. Other compilers might then correctly report an
>> >>> assignment without affect...
>> >>
>> >> I have yet to see a double assignment be flagged as assignment without
>> >> effect. If it _does_ occur then we have to disable the warning on the
>> >> compiler that we have less faith in.
>> > Have seen it in the past in a difference project... But you miss my
>> > point:
>> >
>> > Not all warnings indicate bugs PERIOD. Some warning are just wrong...
>>
>> Have you read my follow up? _Many_ Many warnings are wrong. Please
>> respond to that on what the global policy should be. The value of any
>> one particular instance of a warning does not merit discussion.
>
>
> The global policy has never been 'fix all warnings no matter what.' It's
> been 'Look at the warning. If it's a false positive, use judgement about
> whether or not to stifle the compiler.' There are cases I've run into that
> it was impossible to silence the warnings (apart form adding command line
> stuff) for a particular bit of code. Do it one way gcc 4.2 complains. Do it
> another clang complains. appease both and gcc 6 had heart-burn.
>
> So don't gratuitously commit code that fixes warnings on gcc 8. If the
> warning points out a legitimate bug, then that's no brainer yes. If it's a
> false positive, then it's less clear and often times many factors may need
> to be weighed.

Non-actionable warnings are actively detrimental to workflow. They
hide real issues and lead to apathy by developers. If pacifying a
warning is considered undesirable it should be disabled by default
with perhaps a separate mode for enabling it.

-M