Skip to contentSkip to conversation

checkpatch: allow URL >80 chars

PATCH Superseded Andreas Brauchli 2 participants 3 messages Nov 20, 2017 – Nov 21, 2017 Checkpatch

v2 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 checkpatch: allow URL >80 chars

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://...')

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.-+).

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

$rawline is used in the check as comments are removed from $line.

[1] https://tools.ietf.org/html/rfc3986#section-3.1

---
 scripts/checkpatch.pl | 5 +++++
 1 file changed, 5 insertions(+)
scripts/checkpatch.pl +5 -0
index 8b80bac055e4..732d87917f15 100755
@@ -2904,6 +2904,11 @@ sub process {
 			} elsif ($line =~ /^\+.*\bEFI_GUID\s*\(/) {
 				$msg_type = "";
 
+			# URL (w/ minimal padding e.g. "// ")
+			} elsif ($rawline =~ /^\+.*?\b([a-z][\w\.\+\-]*:\/\/\S+[^\s\)\]\.">;,]).*$/i &&
+				 length($rawline) - length($1) <= 4) {
+				$msg_type = "";
+
 			# Otherwise set the alternate message types
 
 			# a comment starts before $max_line_length
Signature · 1 line
2.14.1
maintainer
#1 lore raw
Quoted 8 lines · Andreas Brauchli

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.

Quoted 3 lines

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.

Quoted 2 lines

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

OK.

#2 lore raw
Quoted 4 lines · Joe Perches
Quoted 3 lines · Andreas Brauchli

Allow URL to exceed the 80 char limit for improved interaction in adaption to ongoing but undocumented practice.

Quoted 8 lines
Quoted 6 lines
$ 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.

If it's dropped the line might not be minimal anymore. I.e. there may be content on the same line that could easily be wrapped.

Quoted 5 lines

For instance, this style

	/* some long url */

is pretty common.

I can change the heuristics to not accept word characters outside of the URL match. That would allow whitespace, quotes, braces and comment characters, and thus also the example above.

Quoted 5 lines
Quoted 4 lines

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.-+).

Quoted 7 lines

That seems right, thanks.

Quoted 3 lines

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

OK.

Thanks for the reviews,
Andreas