I really doubt that the result of this is exactly what you want, but maybe
you can improve it.
This critically relies on the function f having a return value. If it
doesn't then you would need two versions, one with a return value and one
without. It also critically relies on the
On Wed, Apr 20, 2016 at 7:57 PM, Julia Lawall wrote:
> On Wed, 20 Apr 2016, Luis R. Rodriguez wrote:
>
>> Is there a way to split a function in 2 with SmPL? For example, let's
>> say I've created a helper routine which accepts a callback to be set,
>> it will then use the
On Wed, 20 Apr 2016, Luis R. Rodriguez wrote:
> Is there a way to split a function in 2 with SmPL? For example, let's
> say I've created a helper routine which accepts a callback to be set,
> it will then use the callback. The code that goes into the callback
> will be the code you had below an
Is there a way to split a function in 2 with SmPL? For example, let's
say I've created a helper routine which accepts a callback to be set,
it will then use the callback. The code that goes into the callback
will be the code you had below an old API call.
For instance I'm writing a new firmware
On Wed, 20 Apr 2016, Kieran Bingham wrote:
>
>
> On 20 Apr 2016 17:31, "Julia Lawall" wrote:
> >
> >
> >
> > On Wed, 20 Apr 2016, Kieran Bingham wrote:
> >
> > > On 20/04/16 16:53, Julia Lawall wrote:
> > > >
> > > > On Wed, 20 Apr 2016, Kieran Bingham wrote:
> > > >
> >
On 20 Apr 2016 17:46, "Julia Lawall" wrote:
>
>
>
> On Wed, 20 Apr 2016, Kieran Bingham wrote:
>
> > Hi all,
> >
> > I am finding that a rule which matches a part of code, sometimes causes
> > hunks which depend on it to act, and sometimes not to act
> >
> > My spatch is
On 20 Apr 2016 17:31, "Julia Lawall" wrote:
>
>
>
> On Wed, 20 Apr 2016, Kieran Bingham wrote:
>
> > On 20/04/16 16:53, Julia Lawall wrote:
> > >
> > > On Wed, 20 Apr 2016, Kieran Bingham wrote:
> > >
> > >> Hi all,
> > >>
> > >> I am finding that a rule which matches a part
On Wed, 20 Apr 2016, Kieran Bingham wrote:
> Hi all,
>
> I am finding that a rule which matches a part of code, sometimes causes
> hunks which depend on it to act, and sometimes not to act
>
> My spatch is successfully removing and converting hunks that I desire
> changed, however the
Hi all,
I am finding that a rule which matches a part of code, sometimes causes
hunks which depend on it to act, and sometimes not to act
My spatch is successfully removing and converting hunks that I desire
changed, however the requirement became apparent *to not process the
file at all* if the
There's ~150 of these in the kernel.
Maybe there's use for this conversion to be added
to scripts/coccinelle/misc/boolreturn.cocci or in
a separate file.
$ cat booltruefalse.cocci
@@
identifier fn;
expression e;
typedef bool;
symbol true;
symbol false;
@@
bool fn ( ... )
{
<...
- if (e)
On Sat, Mar 19, 2016 at 06:43:08PM +0100, Julia Lawall wrote:
> On Sat, 19 Mar 2016, Wolfram Sang wrote:
>
> > The header mentions this check depends on personal taste. I agree.
> > Running coccicheck on patches before I apply them, this SmPL produced
> > enough false positives for me that I'd
Dne 20.3.2016 v 13:25 Julia Lawall napsal(a):
>
>
> On Sun, 20 Mar 2016, Vaishali Thakkar wrote:
>
>> Add space in front of the offending parentheses to silent the
>> parse error for older Coccinelle versions. This makes the rule
>> usable with all Coccinelle versions.
>>
>> Reported-by:
On 04/19/2016 09:15 PM, Julia Lawall wrote:
>
>
> On Tue, 19 Apr 2016, Joe Perches wrote:
>
>> There's ~150 of these in the kernel.
>>
>> Maybe there's use for this conversion to be added
>> to scripts/coccinelle/misc/boolreturn.cocci or in
>> a separate file.
>>
>> $ cat booltruefalse.cocci
>>
13 matches
Mail list logo