linux-kernel - Re: [PATCH] checkpatch: handle utf8 while computing length of commit msg lines

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: <CAHk-=wiQp+H9OeV9bWvzhxhB5vvQJ-=VA9z-YuoEhU=myYtitQ@mail.gmail.com>
Date:   Sat, 22 Oct 2022 11:33:10 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Antonio Borneo <antonio.borneo@...s.st.com>,
        Andy Whitcroft <apw@...onical.com>,
        Dwaipayan Ray <dwaipayanray1@...il.com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] checkpatch: handle utf8 while computing length of commit
 msg lines

On Fri, Oct 21, 2022 at 10:48 PM Joe Perches <joe@...ches.com> wrote:
>
> On Fri, 2022-10-21 at 21:15 +0200, Antonio Borneo wrote:
> >
> > Actually it's not fully clear to me if utf8 characters in the
> > commit msg are acceptable/tolerated or to be avoided.

utf8 is not just acceptable, but actively encouraged in commit
messages. Not *grtatuitous* use (please - no emojis) but there is
absolutely nothing wrong when using utf8 when appropriate.

And getting people's names right is not just appropriate, but actually
important. And depending on where in the world you are from, utf8 is
absolutely required, and no, we don't do Latin1 for that subset of the
world (any more - we have a dark history of Latin1 in some corners).

That said, I'm not convinced the whole line length check really
matters, or is even appropriate. A lot of commit messages absolutely
should have long lines, regardless of any UTF8 issues.

Just as a recent example, see commit 71e2d666ef85 ("mm/huge_memory: do
not clobber swp_entry_t during THP split"), which has a 200+ character
line, and that's *exactly* what it should have. Splitting that line
would be actively wrong. The same often goes for things like quoted
compiler warnings etc.

I personally can't think of a case where we've actually had issues wrt
"line length in bytes vs line length in characters". And I'm not
convinced the length check is appropriate in the first place.

The only line that really shouldn't be overly long is the _first_ line
of the commit message, because that tends to be a "somebody write a
whole paragraph in line-wrapped mode". And the first line of the
commit message really is special, and should not just be of a
reasonable length (although75 chars may be too restrictive), but
should have an empty line after it.

I didn't look into what the checkpatch.pl script does around that
code, maybe that's what it already does.

                       Linus