On 05/24/18 11:00, Matthew Macy wrote:
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.
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.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
