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]

Message-ID: <CANiq72m1E1=7yVz=jrDJWBtLZzDsi0ygFvZaHrOk_EbKdbf38A@mail.gmail.com>
Date:   Mon, 22 Jun 2020 02:03:32 +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

Hi Joe,

I didn't forget about this -- I was playing the other day with
`ColumnLimit: 0` and the new options up to LLVM 11 to see what we
could do... See below.

On Thu, Jun 11, 2020 at 9:26 PM Joe Perches <joe@...ches.com> wrote:
>
> Hey again Miguel:
>
> A little script and some statistics:
>
> Today about 6% of all code lines are > 80 columns
>
> Oddities like the ~3% of all lines with 113 and 121 columns
> are machine generated.
>
> So realistically, < 3% of code is > 80 columns.

The data you show is very useful, thanks! Of course, the current set
of lines tends to be < 80 columns given the previous strongly
preferred limit, but I would expect that % to grow in the future.

By the way, the 20% figure I mentioned was w.r.t. the previous set of
lines that were already over 80 columns (not w.r.t. the total set).

Regarding the changes: `ColumnLimit: 0` could be a good compromise
(which makes `clang-format` respect as much as possible the current
line breaks) to let developers have more leeway. They would still get
warnings from your `checkpatch` etc. On the other hand, making
formatting dependent on the previous state is not something I am a fan
of, particularly for long-term efforts to move to `clang-format`
"completely".

I guess users of `clang-format` should speak up (w.r.t. `ColumnLimit:
100`, `ColumnLimit: 0` or no change). At the end of the day, this is
still just a tool and not enforced, and they can still override it, so
if people start submitting code with 200-wide lines, well, they still
can :-) Otherwise, let's leave it as it is for the moment and see what
is the output of the script in, say, a year.

Cheers,
Miguel