svn commit: r333860 - head/sys/kern

[Pedro Giffuni]

On 05/24/18 11:00, Matthew Macy wrote:
> 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.

False positives are compiler bugs.

It does happen, with GCC more than with clang, that the compiler has too 
many bugs and it's a bad practice to pessimize code to work around 
them.  At very least you should add a comment when adding unnecessary 
initializations, something like /* workaround GCC */, but dropping 
broken warnings is best.

Pedro.