linux-kernel - Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Sep 2016 10:50:44 -0700
From:   Joe Perches <joe@...ches.com>
To:     Al Viro <viro@...IV.linux.org.uk>, Jean Delvare <jdelvare@...e.de>
Cc:     Julia Lawall <julia.lawall@...6.fr>,
        Ilya Dryomov <idryomov@...il.com>,
        Andy Whitcroft <apw@...onical.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Ceph Development <ceph-devel@...r.kernel.org>,
        Alex Elder <elder@...nel.org>, Sage Weil <sage@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-doc@...r.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next

On Thu, 2016-09-22 at 14:11 +0100, Al Viro wrote:
> The main intent of checkpatch these days appears to be providing an easy
> way of thoughtless inflation of commit counts, everything else be damned.

You've made this statement several times over many years.
I don't believe it's true.
I doubt anyone is getting paid per commit.
Who really cares enough to game some stupid little metric?

If it's really a big deal, name some names.  Otherwise please
stop with this dubious argument/point.

> Some of these checks are common-sense, some are
> absolutely arbitrary,

Essentially all of the checkpatch rules are arbitrary.
The compiler doesn't care one way or another.

All the checks exist just to make code appear more consistent.

The conceit being that more consistent code is easier for humans
to read and spot potential defects and possible reuse patterns.