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]
Message-ID: <1375798166.2424.12.camel@joe-AO722>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ