Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

[Jean Delvare]

Hi Peter,

On Tue, 6 Sep 2016 16:47:56 +0200, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote:
> > > [diff "default"]
> > >         xfuncname = "^[[:alpha:]$_].*[^:]$"
> > 
> > OK, I see. As mentioned somewhere else, it fails for labels which have
> > comments. 
> 
> Heh, There's labels that have comments?

Yes, 43.

> > My worry is that you recommending it to contributors on a individual
> > and opportunity basis, doesn't scale. Basing coding style
> > recommendations on a personal quirk doesn't strike me as the best idea
> > ever in the long run.
> 
> Don't care too much, I simply will not take any patch that adds stupid
> spaces :-)
> 
> > While looking at the syntax of your example, I have found something
> > which looks more promising. git already has predefined xfuncname
> > definitions for various languages, including C. These can be enabled
> > based on file name patterns via gitattributes. The
> > following .gitattribute file placed at the root of the kernel source
> > tree achieves what you want:
> > 
> > *.c   diff=cpp
> > *.h   diff=cpp
> > 
> > The major difference between git config and gitattributes is that the
> > latter can be part of the project itself, just like gitignore. So we
> > could just push that .gitattribute file upstream, and then labels
> > without leading spaces would no longer be a problem, at least within
> > git.
> 
> Works for me,

OK, I'll send a patch now.

> and last time this came up Linus agreed with the
> "whitespace before labels is stupid" thing. Although I cannot find a
> link to that just now.

Murphy's law applies, you can never find links again the day you
desperately need them. If you ever get your hands on that one again,
please let me know, I really would like to read that post.

> > It would still be a problem for me as an inveterate quilt user,
> 
> Add the below to your .quiltrc or environment:
> 
> QUILT_DIFF_OPTS="-F ^[[:alpha:]\$_].*[^:]\$"

I didn't know this option existed, thanks for the pointer.

Now I'm sure I won't try to get the behavior of GNU diff option -p
changed, as I think I know what the answer would be.

> Same caveat about labels with comments, but then I'd not take a patch
> doing that in the first place.

I'll improve the regular expression if I ever have to (I don't think a
function declaration can have a colon anywhere?), but I'm happy if it
works in 99.9 % of the cases, thank sagain.

-- 
Jean Delvare
SUSE L3 Support