From owner-svn-src-all@freebsd.org Thu May 24 16:00:20 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75C3EEF645D; Thu, 24 May 2018 16:00:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BD8974A2C; Thu, 24 May 2018 16:00:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id D5FC112010; Thu, 24 May 2018 16:00:19 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-io0-f169.google.com with SMTP id d11-v6so2893610iof.11; Thu, 24 May 2018 09:00:19 -0700 (PDT) X-Gm-Message-State: ALKqPwehGXBwKLIqk/A98t1DoeYhiu97j88Mwhqh6n8j1DL5h5ljmqQW KQ1x5qAZ+1IrKvqzjxgWxrYMQb+te8Ap6hJvyjs= X-Google-Smtp-Source: ADUXVKImno6fbgvmZZRQeNWYj3imVQl2rkFCUXNREcjvjoSYsFkgL5pAtKEXS4LfjlkMWyyK7mn4n4fgEBDIkIc6AZg= X-Received: by 2002:a6b:6707:: with SMTP id b7-v6mr2062618ioc.132.1527177619407; Thu, 24 May 2018 09:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:85ca:0:0:0:0:0 with HTTP; Thu, 24 May 2018 09:00:19 -0700 (PDT) In-Reply-To: References: <201805190510.w4J5AqfS054367@repo.freebsd.org> <20180523222743.GU71675@FreeBSD.org> <20180523225729.GV71675@FreeBSD.org> <20180524044252.GW71675@FreeBSD.org> <5B9EE208-384F-44AD-9B47-059D77FE9B34@macmic.franken.de> From: Matthew Macy Date: Thu, 24 May 2018 09:00:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r333860 - head/sys/kern To: Warner Losh Cc: Michael Tuexen , Gleb Smirnoff , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 16:00:20 -0000 On Thu, May 24, 2018 at 8:58 AM, Warner Losh wrote: > > > On Thu, May 24, 2018 at 12:53 AM, Matthew Macy wrote: >> >> On Wed, May 23, 2018 at 11:42 PM, Michael Tuexen >> wrote: >> >> On 24. May 2018, at 08:36, Matthew Macy wrote: >> >> >> >> On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen >> >> wrote: >> >>>> On 24. May 2018, at 06:51, Matthew Macy 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