linux-kernel - Re: [PATCH v2] checkpatch: allow URL >80 chars

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: <1511244177.6989.24.camel@perches.com>
Date:   Mon, 20 Nov 2017 22:02:57 -0800
From:   Joe Perches <joe@...ches.com>
To:     Andreas Brauchli <a.brauchli@...mentarea.net>,
        Andy Whitcroft <apw@...onical.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] checkpatch: allow URL >80 chars

On Mon, 2017-11-20 at 13:40 +0100, Andreas Brauchli wrote:
> Allow URL to exceed the 80 char limit for improved interaction in
> adaption to ongoing but undocumented practice.
> 
> $ git grep -E '://\S{77}.*' -- '*.[ch]'
> 
> The patch checks that the URL is indeed on its own line in that it
> allows a maximal prefix of 3 characters to account for a URL after a
> comment (e.g. '// https://...')

I think this part is not necessary or that useful.

For instance, this style

	/* some long url */

is pretty common.

> As per RFC3986 [1], the URL format allows for alphanum, +, - and .
> characters in the scheme before the separator :// as long as it starts
> with a letter (e.g. https, git, f.-+).

That seems right, thanks.

> Recognition of URIs without more context information is prone to false
> positives and thus currently left out of the heuristics.

OK.