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

Message-ID: <alpine.LFD.2.00.0904090750370.4583@localhost.localdomain>
Date:	Thu, 9 Apr 2009 08:00:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andy Whitcroft <apw@...onical.com>,
	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrace: checkpatch fixes

On Thu, 9 Apr 2009, Ingo Molnar wrote:
> 
> We should perhaps introduce an too-deep-indentation warning: any 
> function with "[;{}]$" lines of 4 tabs in a row is already suspect 
> IMHO. At 5 it's definitely crazy and ugly.
> 
> This would be a very efficient function-length reductor: it cannot 
> be worked around via line wraps.

People would start using spaces to try to work around it instead, which is 
a worse cure than the problem.

Also, the thing is, a long _individual_ line is not a problem even if you 
have a 80-column terminal. Sane editors will have a marker for "this line 
continues", and even if you have an insane editors that doesn't do that, 
it's pretty obvious - and if you really care about the end of that 
_particular_ line (most of the time you don't), you can just move to that 
line.

So if you have a couple of long lines occasionally, that's not a huge 
problem. In fact, that's why I hate splitting lines so much: the "false 
indentation" that a line split causes is generally much more confusing 
visually (not so much in something like a function header, but often very 
much so inside the code itself).

> It would also be wonderful to warn about bad 80 columns 'fixes' - 
> i've seen way too many perfectly fine cleanups damaged by ugly 
> line-wrapping solutions.

The thing is, it's very hard to warn about those. You need more 
understanding than your average perl-script can ever get.

> We could also up the limit to 90 or 100 columns. My terminals are at 
> 90 columns and that's still pretty ergonomic.

I tend to start out with a 80x24 and just resize it, and end up at some 
random value. It's usually in the 90x40 range for me. But I do want the 
code to be perfectly _readable_ in a 80x24 window, and quite frankly, if 
you look at something like kernel/ptrace.c, it really generally is.

So sure, that "int ptrace_readdata()" line is longer than that, and won't 
show completely. But you don't miss any huge glaring code issues even in 
the truncated mode. In fact, if I try to use 80x24, my biggest issue will 
inevitably be not the 80 part, but the 24 part. 

IOW, I think there is much more reason to hate long _functions_ than there 
is reason to hate long lines. Both cause you to scroll. The long function 
where there is action over more than 24 lines happens a lot more.

					Linus
--
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/