Re: [Cocci] Checking software behaviour according to selected SmPL code variants
>> @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 when you have is useless. I am curious under which circumstances we will achieve a better common understanding for the shown application of SmPL disjunctions eventually together with additional code exclusion specifications. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
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(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 when you have is useless. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
>> 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 if I do not need to repeat a code exclusion specification as the first element of a SmPL disjunction for this special use case. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
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/ext4/extents.c > >> … > >> @@ -1127,8 +1121,6 @@ static int ext4_ext_split(handle_t *hand > … > >> - brelse(bh); > >> - bh = NULL; > … > >> Would you like to suggest any fine-tuning for the search approach? > > > > When describes what happens elsewhere than in the statement matched by the > > pattern. > > 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 )___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
>> @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(handle_t *hand … >> -brelse(bh); >> -bh = NULL; … >> Would you like to suggest any fine-tuning for the search approach? > > When describes what happens elsewhere than in the statement matched by the > pattern. I hoped that my specification of a SmPL code exclusion should prevent the presentation of assignments (independent from statements and/or expressions). Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
> 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.
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(handle_t *hand
err = ext4_handle_dirty_metadata(handle, inode, bh);
if (err)
goto cleanup;
- brelse(bh);
- bh = NULL;
/* correct old leaf */
if (m) {
…
Would you like to suggest any fine-tuning for the search approach?
Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
>> 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 area. > When you put <+... ...+> in an argument list, it doesn't mean an unknown > number > of arguments, it means one arguemnt that has something as a subexpression. Another SmPL code variant can eventually become interesting then. *y = x(..., <+... e ...+>, ...) >> If I omit even the semicolon from the assignment statement in the >> search pattern, I get an error message. >> >> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci >> show_questionable_brelse_usage6.cocci >> … >> minus: parse error: >> File "show_questionable_brelse_usage6.cocci", line 6, column 0, charpos = >> 67 >> around = '', >> whole content = > > That is quite normal. One statement should be followed by another statement. I hope that the support will become better also for assignment expressions. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking software behaviour according to selected SmPL code variants
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 for the semantic patch language
> (according to the software combination “Coccinelle 1.0.8-00104-ge06b9156”).
>
>
> @display@
> expression e, x, y;
> @@
> *brelse(e);
> *y = x(<+... e ...+>, ...);
>
>
> An usable output is generated then as expected for a test source file
> like the following.
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/fs/exfat/nls.c?id=b676fdbcf4c8424f3c02ed7f31576d99b963bded#n652
>
> // SPDX-License-Identifier: GPL-2.0-or-later
> // deleted part
> static int exfat_load_upcase_table(struct super_block *sb,
> sector_t sector, unsigned long long num_sectors,
> unsigned int utbl_checksum)
> {
> struct exfat_sb_info *sbi = EXFAT_SB(sb);
> unsigned int sect_size = sb->s_blocksize;
> unsigned int i, index = 0;
> u32 chksum = 0;
> // deleted part
> while (sector < num_sectors) {
> struct buffer_head *bh;
>
> bh = sb_bread(sb, sector);
> // deleted part
> brelse(bh);
> chksum = exfat_calc_chksum32(bh->b_data, i, chksum, CS_DEFAULT);
> }
> // deleted part
> }
> // deleted part
>
>
> 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. When you put <+... ...+> in an argument
list, it doesn't mean an unknown number of arguments, it means one
arguemnt that has something as a subexpression.
>
> If I omit even the semicolon from the assignment statement in the
> search pattern, I get an error message.
>
> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci
> show_questionable_brelse_usage6.cocci
> …
> minus: parse error:
> File "show_questionable_brelse_usage6.cocci", line 6, column 0, charpos = 67
> around = '',
> whole content =
That is quite normal. One statement should be followed by another
statement.
>
> Will such observations influence subsequent software evolution?
No.
julia___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
