linux-kernel - Re: [PATCH 02/10] drivers/ata: Fix continuation line formats

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: <4B6AD4B2.7070406@teksavvy.com>
Date:	Thu, 04 Feb 2010 09:07:46 -0500
From:	Mark Lord <kernel@...savvy.com>
To:	Joe Perches <joe@...ches.com>
CC:	Sergey Matyukevich <geomatsi@...il.com>,
	linux-kernel@...r.kernel.org, Jeff Garzik <jgarzik@...ox.com>,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH 02/10] drivers/ata: Fix continuation line formats

Joe Perches wrote:
> If it's ever agreed that all lines > 80 cols are OK or
> new args after column 80 are OK, then sure.  Until then,
> if you want it, you should do it.
..

In case you missed it, it *has* already been "agreed" that
there's nothing magical about 80 anymore.  

-------- Original Message --------
Subject: Re: [PATCH] ptrace: checkpatch fixes
Date: Wed, 8 Apr 2009 10:19:36 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Roland McGrath <roland@...hat.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,	linux-kernel@...r.kernel.org
References: <20090408062106.39EE0FC3E5@...illa.sf.frob.com>

On Tue, 7 Apr 2009, Roland McGrath wrote:
>
> This fixes all the checkpatch --file complaints about kernel/ptrace.c
> and also removes an unused #include.  I've verified that there are no
> changes to the compiled code on x86_64.

Please don't bother with that insane "line length" option when using 
"--file". At least not if the "fix" is to just mindlessly split the line. 
That is _never_ a fix.

Changes like these:

> -int ptrace_readdata(struct task_struct *tsk, unsigned long src, char __user *dst, int len)
> +int ptrace_readdata(struct task_struct *tsk, unsigned long src,
> +		    char __user *dst, int len)

> -int ptrace_writedata(struct task_struct *tsk, char __user *src, unsigned long dst, int len)
> +int ptrace_writedata(struct task_struct *tsk, char __user *src,
> +		     unsigned long dst, int len)

>  	case PTRACE_GETEVENTMSG:
> -		ret = put_user(child->ptrace_message, (unsigned long __user *) data);
> +		ret = put_user(child->ptrace_message,
> +			       (unsigned long __user *) data);

just make the code harder to 'grep'.

Yes, at some point you have to split lines, but that point is not 80
columns any more.  The advantage of getting the whole line when grepping
for function names much outweighs the downside of somebody using those
old 80x24 green phosphorous vt52's.

[ The same thing very much goes for complex if-statements etc.  If
  people can't stand the long lines, the primary solution would be to
  turn a complex conditional into a helper inline functions, or to fix
  excessive indentation by splitting up functions.

  In the above case, the last one could perhaps have been handled
  creating a new variable for and moving the cast to the initialiser,
  for example. Is it worth it to avoid a 85-column line? Probably not.

  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. 

			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/