linux-kernel - Re: [PATCH] ptrace: checkpatch fixes

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]

Date:	Wed, 8 Apr 2009 21:57:54 +0200
From:	Christian Borntraeger <borntraeger@...ibm.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrace: checkpatch fixes

Am Wednesday 08 April 2009 19:19:36 schrieb Linus Torvalds:
>   And some lines just end up long.  I think 100 characters may be a
>   more reasonable limit for "too long", but quite frankly, it depends on
>   the line.
> 
>   So I think 'checkpatch' is pure crap in this area, and I've told
>   people so before, and they keep telling me that it has relaxed it's
>   idiotic warnings, but that is apparently just a lie. ]
> 
> Oh well.  If I actually read perl, I could parse what the hell those
> 80-character rules are in checkpath.  It already has random "it's ok if
> X" stuff.  But it never seems to really have any "oh, but splitting is
> worse" logic. 

Isnt checkpatch just following what is written down in the Documentation folder? Maybe adopting the following part of CodingStyle and add more examples for good and bad would give the checkpatch authors a better idea about your intent.

--------- snip---------
                Chapter 2: Breaking long lines and strings

Coding style is all about readability and maintainability using commonly
available tools.

The limit on the length of lines is 80 columns and this is a strongly
preferred limit.

Statements longer than 80 columns will be broken into sensible chunks.
Descendants are always substantially shorter than the parent and are placed
substantially to the right. The same applies to function headers with a long
argument list. Long strings are as well broken into shorter strings. The
only exception to this is where exceeding 80 columns significantly increases
readability and does not hide information.

void fun(int a, int b, int c)
{
        if (condition)
                printk(KERN_WARNING "Warning this is a long printk with "
                                                "3 parameters a: %u b: %u "
                                                "c: %u \n", a, b, c);
        else
                next_statement;
}
----------snip---------

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/