linux-kernel - Re: [PATCH 1/1] checkpatch: fix some whitespace issues caused by --fix

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 06 Aug 2013 07:09:26 -0700
From:	Joe Perches <joe@...ches.com>
To:	Phil Carmody <phil.carmody@...tner.samsung.com>
Cc:	apw@...onical.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] checkpatch: fix some whitespace issues caused by
 --fix

On Tue, 2013-08-06 at 11:05 +0300, Phil Carmody wrote:
> > On Mon, 2013-08-05 at 14:08 +0300, Phil Carmody wrote:
> > > Lines with incorrect spacing around an operator, such as:
> > >   bystander, correct,incorrect
> > > would get "fixed" to
> > >   bystander,correct, incorrect
> > > as the correct argument as well as the incorrectly-spaced operator
> > > were both being trimmed. The correct argument only needs to be right
> > > trimmed.
> > 
> > Thanks for the patch, but I think it needs a different fix.
> 
> I think it's the right approach, but you're right,
> fix all the problems. However, in part that's because many 
> copies of the string, or bits of it, are created, and when 
> one copy is modified, the others don't replicate that change.
> 
> > Even after your patch the --fix option still makes a mess of several
> > code spacing issues.
> 
> Indeed. Just seen - func(foo,&bar); becoming func(foo,  &bar);, 
> as --fix wants to put a space both after the ',' and before the '&'.

Hi Phil.

Basically, checkpatch needs to left trim the
"$fix_elements[$n + 2])" if it exists.

> > I'll work on it and propose something soonish.
> 
> It's very much a WIP - I'll send my bride-of-checkpatch to you 
> as soon as I've written some blurb. It might be that the 
> complexities inside checkpatch can't be overcome, and it's
> easier to address the changes entirely in a separate script?

Maybe, but humans are lazy.

Maybe the "bride-of" approach will work better,
It's hard to know right now.  No worries, you try
yours too and one or the other or both might be
the "right" approach.

btw:

The biggest complexity might be handling patches
that need lines added or removed by rewriting
the patch contexts.

Maybe creating an interdiff would be better than
rewriting the patch or file.

I was too lazy to do that to checkpatch for a
first pass.


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