All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Bowler <nbowler@elliptictech.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: linux-kernel@vger.kernel.org, Andy Whitcroft <apw@canonical.com>,
	Joe Perches <joe@perches.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 15:22:07 -0500	[thread overview]
Message-ID: <20120202202207.GA10041@elliptictech.com> (raw)
In-Reply-To: <20120202200621.GB9279@leaf>

On 2012-02-02 12:06 -0800, Josh Triplett wrote:
> Documentation/CodingStyle recommends not splitting quoted strings across
> lines, because it breaks the ability to grep for the string.  checkpatch
> already makes an exception to the 80-column rule for quoted strings to
> allow this.  Rather than just allowing it, actively warn about quoted
> strings split across lines.
[...]
> +# Check for strings broken across lines (breaks greppability).  Make an
> +# exception when the previous string ends in a newline (multiple lines in one
> +# string constant) or \n\t (common in inline assembly to indent the instruction
> +# on the following line).

There are tons of strings in the kernel that this makes checkpatch warn
about where it probably shouldn't.  For example, this one (from
kernel/auditsc.c:1476):

  		audit_log_format(ab,
  			"oflag=0x%x mode=%#ho mq_flags=0x%lx mq_maxmsg=%ld "
  			"mq_msgsize=%ld mq_curmsgs=%ld",

  WARNING: quoted string split across lines
  #1478: FILE: auditsc.c:1478:
  +			"mq_msgsize=%ld mq_curmsgs=%ld",

Breaking "greppability" of this string is a non-issue, because this sort
of string is not really greppable to begin with (and would certainly not
be any easier to grep for if it were all on one line).

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)


  reply	other threads:[~2012-02-02 20:22 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 [this message]
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
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=20120202202207.GA10041@elliptictech.com \
    --to=nbowler@elliptictech.com \
    --cc=apw@canonical.com \
    --cc=joe@perches.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.