Hello,
My software development attention was caught also by a recent patch.
https://lore.kernel.org/linux-fsdevel/20200608141629.GA1912173@mwanda/
https://lore.kernel.org/patchwork/patch/1253499/
Thus I have tried another tiny script out for the semantic patch language
(according to the software
On Tue, 9 Jun 2020, Markus Elfring wrote:
> Hello,
>
> My software development attention was caught also by a recent patch.
> https://lore.kernel.org/linux-fsdevel/20200608141629.GA1912173@mwanda/
> https://lore.kernel.org/patchwork/patch/1253499/
>
> Thus I have tried another tiny script out fo
>> If I omit the specification “, ...” from the function call parameters
>> because I could be unsure about the number of arguments in other
>> software situations, I do not get the desired test output as before.
>
> This has been discussed before.
I was just looking for a related update in this a
> That is quite normal. One statement should be followed by another statement.
I have tried another script variant out for the semantic patch language.
@display@
expression e;
@@
*brelse(e);
<+... when != e = ...
*e
...+>
I wonder about the generation of a diff hunk then like the following.
>> @display@
>> expression e;
>> @@
>> *brelse(e);
>> <+... when != e = ...
>> *e
>> ...+>
…
>> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
>> ~/Projekte/Coccinelle/janitor/show_questionable_brelse_usage8.cocci
>> fs/ext4/extents.c
>> …
>> @@ -1127,8 +1121,6 @@ static int ext4_ext_split
On Wed, 10 Jun 2020, Markus Elfring wrote:
> >> @display@
> >> expression e;
> >> @@
> >> *brelse(e);
> >> <+... when != e = ...
> >> *e
> >> ...+>
> …
> >> elfring@Sonne:~/Projekte/Linux/next-patched> spatch
> >> ~/Projekte/Coccinelle/janitor/show_questionable_brelse_usage8.cocci
> >> fs/ex
>> I hoped that my specification of a SmPL code exclusion should prevent
>> the presentation of assignments (independent from statements and/or
>> expressions).
>
> (
> e = e1
> |
> *e
> )
@display@
expression e;
@@
*brelse(e);
<+... when != e = ...
(e = ...
|
*e
)...+>
I would find it nicer i
On Wed, 10 Jun 2020, Markus Elfring wrote:
> >> I hoped that my specification of a SmPL code exclusion should prevent
> >> the presentation of assignments (independent from statements and/or
> >> expressions).
> >
> > (
> > e = e1
> > |
> > *e
> > )
>
> @display@
> expression e;
> @@
> *brelse
>> @display@
>> expression e;
>> @@
>> *brelse(e);
>> <+... when != e = ...
>> (e = ...
>> |
>> *e
>> )...+>
>>
>>
>> I would find it nicer if I do not need to repeat a code exclusion
>> specification
>> as the first element of a SmPL disjunction for this special use case.
>
> You don't. The whe