[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160906163413.470f37d4@endymion>
Date: Tue, 6 Sep 2016 16:34:13 +0200
From: Jean Delvare <jdelvare@...e.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Jonathan Corbet <corbet@....net>,
David Miller <davem@...emloft.net>, sparclinux@...r.kernel.org,
Adam Buchbinder <adam.buchbinder@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Rabin Vincent <rabin@....in>, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org,
Julia Lawall <julia.lawall@...6.fr>,
Paolo Bonzini <pbonzini@...hat.com>, linux-doc@...r.kernel.org
Subject: Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()
Hi Peter,
On Mon, 5 Sep 2016 13:58:38 +0200, Peter Zijlstra wrote:
> On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote:
> > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote:
> > > I have it in my local .gitconfig, and recommend it to people who send me
> > > patches.
> >
> > What does it look like, please?
>
> [diff "default"]
> xfuncname = "^[[:alpha:]$_].*[^:]$"
OK, I see. As mentioned somewhere else, it fails for labels which have
comments. I was also surprised by the $ but apparently it's valid in
identifiers for at least some incarnations of C o.O
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.
The reason why I proposed an update to CodingStyle regarding this topic
was precisely to avoid having to repeat the same to contributors, like
you do (although our recommendations are different.)
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. It would still be a problem for me as an inveterate quilt user, at
least until GNU diff gets "fixed." Which I did not even try, as I'm not
sure if upstream really considers this a bug in the first place.
And just for completeness, git's "cpp" predefined pattern doesn't
actually support $ as part of identifiers.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists