lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f665ec7b21527c7095a61dd5c2f48fd00df0d5c9.camel@perches.com>
Date:   Wed, 30 Oct 2019 12:23:45 -0700
From:   Joe Perches <joe@...ches.com>
To:     Dan Carpenter <dan.carpenter@...cle.com>, shuah <shuah@...nel.org>
Cc:     David Gow <davidgow@...gle.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, kunit-dev@...glegroups.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH linux-kselftest/test v6] lib/list-test: add a test for
 the 'list' doubly linked list

On Wed, 2019-10-30 at 22:12 +0300, Dan Carpenter wrote:
> On Wed, Oct 30, 2019 at 10:27:12AM -0600, shuah wrote:
> > > It's better to ignore checkpatch and other scripts when they are wrong.
> > > (unless the warning message inspires you to make the code more readable
> > > for humans).
> > > 
> > 
> > It gets confusing when to ignore and when not to. It takes work to
> > figure out and it is subjective.
> > 
> 
> In this case, it's not subjective because checkpatch is clearly not
> working as intended.

checkpatch _is_ working as intended.
It was never intended to be perfect.

checkpatch _always_ depended on a reviewer deciding
whether its output was appropriate.

> I don't feel like "checkpatch clean" is a useful criteria for applying
> patches.

Nor do I.

> The other things about warnings is that I always encourage people to
> just ignore old warnings.  If you're running Smatch and you see a
> warning in ancient code that means I saw it five years ago and didn't
> fix it so it's a false positive.  Old warnings are always 100% false
> positives.

That'd be not absolute either because it depended on your
historical judgment as to whether an old warning was in fact
a defect or not.

People make mistakes.
Regex based scripts are by design stupid and untrustworthy.

Mistakes will be made.
Just fix the actual defects in code as soon as possible.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ