All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Joe Perches <joe@perches.com>
Cc: Jesper Juhl <jj@chaosbits.net>,
	Nick Bowler <nbowler@elliptictech.com>,
	linux-kernel@vger.kernel.org, Andy Whitcroft <apw@canonical.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] checkpatch: Check for quoted strings broken across lines
Date: Thu, 2 Feb 2012 14:02:22 -0800	[thread overview]
Message-ID: <20120202220222.GC11308@leaf> (raw)
In-Reply-To: <1328218456.18641.60.camel@joe2Laptop>

On Thu, Feb 02, 2012 at 01:34:16PM -0800, Joe Perches wrote:
> On Thu, 2012-02-02 at 22:29 +0100, Jesper Juhl wrote:
> > But generally a good idea to warn about "easily grepable strings broken 
> > into multiple lines" if possible, IMHO...
> 
> Maybe count the %'s?  Ignore if more than 2?

Numerous greppable strings include several formats, but you can
generally look at a message and know which non-parameterized bits to
grep for.  Even in the case of strings with numerous parameters, it
often works better to grep for the whole string and replace the
parameters with '.*', and make the string incrementally less specific
until I find it.  For example, from dmesg on my system:

[    0.000000] last_pfn = 0xdb000 max_arch_pfn = 0x400000000

Grepping for "last_pfn" or even "last_pfn = " produces a pile of
results, but grepping for 'last_pfn = .* max_arch_pfn' produces exactly
one result:

arch/x86/kernel/e820.c: printk(KERN_INFO "last_pfn = %#lx max_arch_pfn = %#lx\n",

That wouldn't work if the string broke across lines.  So, I still think
it seems reasonable for checkpatch to encourage keeping such strings
un-split.

- Josh Triplett

  reply	other threads:[~2012-02-02 22:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 20:06 [PATCH] checkpatch: Check for quoted strings broken across lines Josh Triplett
2012-02-02 20:22 ` Nick Bowler
2012-02-02 21:16   ` Josh Triplett
2012-02-02 22:08     ` Nick Bowler
2012-02-03  1:31       ` Josh Triplett
2012-02-02 21:29   ` Jesper Juhl
2012-02-02 21:34     ` Joe Perches
2012-02-02 22:02       ` Josh Triplett [this message]
2012-02-02 20:36 ` Joe Perches
2012-02-02 21:28   ` Josh Triplett
2012-02-02 21:32     ` Joe Perches
2012-02-02 22:36       ` Josh Triplett
  -- strict thread matches above, loose matches on Subject: below --
2012-02-03  5:27 Josh Triplett
2012-02-03  5:38 ` Joe Perches
2012-02-03  8:55   ` Josh Triplett
2012-02-03  6:34 ` Josh Triplett
2012-03-20 21:06 Josh Triplett
2012-03-21  1:24 ` Joe Perches
2012-03-21  4:28   ` Josh Triplett
2012-03-21  4:35     ` Joe Perches
2012-03-21  6:05       ` Josh Triplett
2012-03-21 12:11         ` Joe Perches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120202220222.GC11308@leaf \
    --to=josh@joshtriplett.org \
    --cc=apw@canonical.com \
    --cc=jj@chaosbits.net \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbowler@elliptictech.com \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.