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: <20200610173209.otq4nxx3ya6j4pat@wittgenstein>
Date:   Wed, 10 Jun 2020 19:32:09 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        linux-kernel@...r.kernel.org, clang-built-linux@...glegroups.com,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] .clang-format: update column limit

On Wed, Jun 10, 2020 at 10:13:24AM -0700, Joe Perches wrote:
> On Wed, 2020-06-10 at 14:51 +0200, Christian Brauner wrote:
> > The provided clang-format file wraps at 80 chars. If noone minds I'd like
> > to adjust this limit to 100 similar to what checkpatch (cf. [1]) uses now.
> > 
> > [1]: commit bdc48fa11e46 ("checkpatch/coding-style: deprecate 80-column warning")
> > Signed-off-by: Christian Brauner <christian.brauner@...ntu.com>
> []
> > diff --git a/.clang-format b/.clang-format
> []
> > @@ -52,7 +52,7 @@ BreakConstructorInitializersBeforeComma: false
> >  #BreakConstructorInitializers: BeforeComma # Unknown to clang-format-4.0
> >  BreakAfterJavaFieldAnnotations: false
> >  BreakStringLiterals: false
> > -ColumnLimit: 80
> > +ColumnLimit: 100
> 
> Ii think this is a not a good change.
> 
> If you read the commit log you provided, it ways
> "staying withing 80 columns is certainly still _preferred_"

I read it; that's why the "if noone minds" is there.

> 
> With this change, clang would _always_ wrap to 100 columns.
> 
> clang would not make any reasonable attempt to use 80 when
> it should.

You make it sounds like it caps all lines to 100 columns when really it
just does it for corner cases where we run over the 80 anwyways. I at
least don't regularly write lines of code that cross the 80 limit.
So when clang-format is called it's usually when something needs to be
reformatted at which point using the more lenient 100 char limit seems
sensible. But I don't particulary care about this patch. I can just
override the .clang-format file if this shakes the world too much.

Christian