linux-kernel - Re: [PATCH 2/2] staging:android:fix line over 80 characters issue in binders.c this patch fixes line over 80 characters warning that was found using checkpatch.pl tool Signed-off-by:Anirudh Bhat <abhat38@...il.com>

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]

Date:	Tue, 24 Apr 2012 21:11:41 -0400
From:	Calvin Walton <calvin.walton@...stin.ca>
To:	David Howells <dhowells@...hat.com>
Cc:	anirudh bhat <abhat38@...il.com>, arve@...roid.com,
	chris+android@...thought.org, hpa@...or.com,
	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
	anirudh bhat <anirudhbhat@...ntu.ubuntu-domain>
Subject: Re: [PATCH 2/2] staging:android:fix line over 80 characters issue
 in binders.c this patch fixes line over 80 characters warning that was
 found using checkpatch.pl tool Signed-off-by:Anirudh Bhat
 <abhat38@...il.com>

On Thu, 2012-04-19 at 09:22 +0100, David Howells wrote:
> anirudh bhat <abhat38@...il.com> wrote:
> 
> > -		printk(KERN_ERR "binder: %d: binder_alloc_buf failed to "
> > -		       "map pages in userspace, no vma\n", proc->pid);
> > +		printk(KERN_ERR "binder: %d: binder_alloc_buf failed to map pages in userspace, no vma\n",
> > +			proc->pid);
> 
> Are these the wrong way round?  Surely these are introducing checkpatch
> warnings rather than curing them?
> 
> If checkpatch is complaining about:
> 
> 	printk(KERN_ERR "binder: %d: binder_alloc_buf failed to "
> 	       "map pages in userspace, no vma\n", proc->pid);
> 
> being a string split over multiple lines, then *checkpatch* needs to be fixed.

This check was added to checkpatch on purpose, with the intention of
allowing you to use e.g.
$ git grep 'failed to match pages'
to find out where in the kernel source the message came from. If the
string is split and wrapped, that doesn't work.

This is mentioned as a recommendation in Documentation/CodingStyle as
well:
> Statements longer than 80 columns will be broken into sensible chunks, unless
> exceeding 80 columns significantly increases readability and does not hide
> information. 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. However, never break user-visible strings such as
> printk messages, because that breaks the ability to grep for them.

-- 
Calvin Walton <calvin.walton@...stin.ca>

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