On Sat, 17 Oct 2020, Joe Perches wrote:
> On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > From: Tom Rix
> >
> > This is a upcoming change to clean up a new warning treewide.
> > I am wondering if the change could be one mega patch (see below) or
> > normal patch per file about
On Sat, 2020-10-17 at 20:21 +0200, Julia Lawall wrote:
> On Sat, 17 Oct 2020, Joe Perches wrote:
> > On Sat, 2020-10-17 at 09:09 -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am wondering if the change could be
> Would you like to look for software configuration alternatives for better
> parallel data processing?
I would like to share another source code analysis approach.
I hope that this contribution can trigger further helpful software development
ideas.
@initialize:python@
@@
import sys
def
> …
> > +E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> > + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> > + kmalloc_array_node\|kcalloc_node\)(...)@kok
> …
>
> How do you think about the possibility for any adjustments according to the
> order
> of the mentioned function
switch/case use of break after a return or goto is unnecessary.
There is an existing warning for these uses, so add a --fix option too.
Signed-off-by: Joe Perches
---
For today's next, this would remove ~300 instances like:
case FOO:
return bar;
break;
> > Can such facts influence the specification of efficient SmPL disjunctions
> > another bit?
>
> On my machine, putting the three functions that you have foudn to be the
> most frequent at the end of each disjunction has no impact on the performance.
I propose to reconsider this view.
> So
I like!
On 10/18/20 12:49 PM, Joe Perches wrote:
> switch/case use of break after a return or goto is unnecessary.
>
> There is an existing warning for these uses, so add a --fix option too.
>
> Signed-off-by: Joe Perches
> ---
>
> For today's next, this would remove ~300 instances like:
>
>
On Sun, 2020-10-18 at 13:07 -0700, Tom Rix wrote:
> I like!
[]
> could add a '|break' here to catch the couple
[]
> break;
>
> break;
Unfortunately, checkpatch is really stupid and it
wouldn't catch those
cases as there are blank lines
between the existing consecutive break
statements.
It would
On Sun, 18 Oct 2020, Markus Elfring wrote:
> > …
> > > +E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> > > + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> > > + kmalloc_array_node\|kcalloc_node\)(...)@kok
> > …
> >
> > How do you think about the possibility for any
