netdev - Re: [PATCH iproute2-next] add .editorconfig file for basic formatting

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

Message-ID: <CAMZ6RqK_+r2OAFtug34vczgqGWodddy282wu6BrO+reYj0Q2UA@mail.gmail.com>
Date: Sat, 16 Nov 2024 11:59:42 +0900
From: Vincent Mailhol <mailhol.vincent@...adoo.fr>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: netdev@...r.kernel.org, David Ahern <dsahern@...il.com>
Subject: Re: [PATCH iproute2-next] add .editorconfig file for basic formatting

On Sat. 16 Nov. 2024 at 05:32, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Sat, 16 Nov 2024 02:59:01 +0900
> Vincent Mailhol <mailhol.vincent@...adoo.fr> wrote:
>
> > > [*]
> > > end_of_line = lf
> > > insert_final_newline = true
> > > trim_trailing_whitespace = true
> >
> > Just let me confirm this one: do you really want the automatic
> > whitespace removal? On some editor, it will trim not only the modified
> > lines but also any whitespace in the full file.
> >
> > This can create "noise" in the patch diff. If you acknowledge this risk,
> > then I am fine to keep this parameter.
>
>
> Yes, emacs and some other editors have bad habit of leaving trailing
> whitespace. And sometimes new files get added without new line at end.

Ack. trim_trailing_whitespace = true will be added back in v2.

> Line length should be 100 like kernel.

It is a bit more nuanced.

  1. On the code, the official limit remains 80:

       https://www.kernel.org/doc/html/latest/process/coding-style.html#breaking-long-lines-and-strings

     Since below commit on checkpatch.pl:

       https://git.kernel.org/torvalds/c/bdc48fa11e46

     warnings are indeed only produced for exceeding the 100th column,
     but as far as I can see, the 80 column limit is still broadly
     followed on kdoc comment blocks and on all the documentation.

  2 .Commit are wrapped at 75 columns:

       https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format

    When I applied the max_line_length = 100 parameter, emacs started
    wrapping the body of my commits to the 100th column. I will add:

      [COMMIT_EDITMSG]
      max_line_length = 75

    to the v2 to prevent this.

In v2, I will apply your suggestion of a broad max_line_length = 100
configuration, with a max_line_length = 75 exception for the commit
messages. I am happy to take any of your suggestions as long as you
agree on the risk and potential side effects!

Yours sincerely,
Vincent Mailhol