linux-kernel - Re: [PATCH] .clang-format: update column limit

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]

Date:   Thu, 11 Jun 2020 20:51:16 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Christian Brauner <christian.brauner@...ntu.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] .clang-format: update column limit

On Thu, Jun 11, 2020 at 6:22 PM Joe Perches <joe@...ches.com> wrote:
>
> On Thu, 2020-06-11 at 13:54 +0200, Miguel Ojeda wrote:
> > Why is 80 "still preferred" to begin with?
>
> That's neither my nor your issue to solve.

? You (or Linus, I still don't know since the commit is on your name
but I can't find the full patch in the list...) updated the wording on
`coding-style.rst` and I have to decide what limit to put into
`ColumnLimit` to make `clang-format` most useful for developers within
the new constraints. So it does concern us...

In my view, `coding-style.rst` is saying what it used to say from the
point of view of a new contributor. But regardless of that, forcing
`clang-format` to work under the 80-column constraint means we will
get code that won't look as good as giving it a slightly higher hard
limit. Yes, more lines will get over 80, but that is not as big of a
concern now since it is not as "strongly preferred" as before, which
is the point I was trying to make.

A concern for keeping the `clang-format` limit as it is that I can
think of is that newcomers using `clang-format` may feel forced not to
go over 80-column no matter what since "that is what the tool does".
On the other hand, my concern for *increasing* it is about things like
function signatures, since there is no easy way to decrease their
length or rearrange them without reducing the identifiers' length. A
third alternative is using `ColumnWidth: 0` and let people break lines
on their own, `clang-format` will respect that if possible. But then
we rely on people using `checkpatch` and they have to take care of the
limit themselves, so the advantage of automatic formatting decreases.

By the way, I noticed that a lot of kernel code will still trigger the
100-column warning (~20% of the previous set triggering it!).

Cheers,
Miguel