linux-kernel - Re: [PATCH v2] clang-format: add configuration file

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] [day] [month] [year] [list]

Message-ID: <CANiq72=GbjqowrGsz77XcTNX0SFyomDVNc=ysnBXuFEr6tfKAw@mail.gmail.com>
Date:   Sun, 18 Mar 2018 19:59:02 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Andy Whitcroft <apw@...onical.com>,
        Jonathan Corbet <corbet@....net>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] clang-format: add configuration file

On Sun, Mar 18, 2018 at 7:26 PM, Joe Perches <joe@...ches.com> wrote:
> On Sun, 2018-03-18 at 18:16 +0100, Miguel Ojeda wrote:
>>   * Uses clang's tooling support behind the scenes to parse and rewrite
>>     the code. It is not based on ad-hoc regexps.
>
> Did you look at the results of a typical and generally
> style conforming
> subsystem when reformatted with the new
> rules you propose here with
> clang-format?

Yeah, of course. The rules are trying to minimize the diffs across
kernel/ and some other places I tried.

Of course, I didn't test every place -- anyway, it does not make sense
to try everywhere, because there are several different styles around
and because of the limitations of the tool itself. Therefore, I
attempted to provide the best set of defaults I could find for
clang-format >= 4.

Also, note that people can override them for subsystems/folders by
providing their own .clang-format in their subfolder. Not that such a
thing will/should be common, but it could be useful for a few places.

>
> One of the issues with hard-n-fast code formatters like
> clang-format is taste.
>
> clang-format doesn't have any so it can't know when _not_
> to  reformat blocks according to its rules.
>
> Tools like clang-format are generally fine for a first-pass
> reformat of non-style compliant code, but are IMO generally
> unsuitable for continuous automated use.

Agreed with all that -- but I am unsure why you are making the remark.

Hmm... I am guessing you read what you quoted above as "let's rewrite
all the code"? :-) It does not say that -- what I tried to say is that
clang-format rewrites code (i.e. formats) by using the compiler
tooling support, not that we are going to use it to rewrite everything
around.

Note that there is support for disabling formatting of blocks in a
file, but I don't think it should be used anyway; at least not now.
The documentation included emphasizes this as well.

Cheers,
Miguel