On Thu, May 24, 2018 at 8:58 AM, Warner Losh <i...@bsdimp.com> wrote: > > > On Thu, May 24, 2018 at 12:53 AM, Matthew Macy <mm...@freebsd.org> wrote: >> >> On Wed, May 23, 2018 at 11:42 PM, Michael Tuexen >> <michael.tue...@macmic.franken.de> wrote: >> >> On 24. May 2018, at 08:36, Matthew Macy <mm...@freebsd.org> wrote: >> >> >> >> On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen >> >> <michael.tue...@macmic.franken.de> wrote: >> >>>> On 24. May 2018, at 06:51, Matthew Macy <mm...@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 _______________________________________________ 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"