* [Cocci] please help me with a failing match
@ 2018-02-10 12:12 Robert Larice
2018-02-10 13:23 ` Julia Lawall
0 siblings, 1 reply; 7+ messages in thread
From: Robert Larice @ 2018-02-10 12:12 UTC (permalink / raw)
To: cocci
Dear People,
I'm completely new here.
Attached is a small piece of .c and a .cocci file.
There is a "return 41;" in both files, commented out.
If I uncomment this "return 41;" in both files then
spatch will not match the pieces any more.
Could you please help me to undertand and circumvent this issue ?
Best Regards,
Robert Larice
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: try-goto-2.cocci
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180210/7f5c486b/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try-goto-2.c
Type: text/x-csrc
Size: 94 bytes
Desc: not available
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180210/7f5c486b/attachment.bin>
^ permalink raw reply [flat|nested] 7+ messages in thread* [Cocci] please help me with a failing match 2018-02-10 12:12 [Cocci] please help me with a failing match Robert Larice @ 2018-02-10 13:23 ` Julia Lawall 2018-02-10 15:04 ` Robert Larice 0 siblings, 1 reply; 7+ messages in thread From: Julia Lawall @ 2018-02-10 13:23 UTC (permalink / raw) To: cocci On Sat, 10 Feb 2018, Robert Larice wrote: > Dear People, > > I'm completely new here. > > Attached is a small piece of .c and a .cocci file. > There is a "return 41;" in both files, commented out. > If I uncomment this "return 41;" in both files then > spatch will not match the pieces any more. > > Could you please help me to undertand and circumvent this issue ? I have not noticed this problem before, but I suspect that it is due to the fact that Coccinelle is matching the control-flow path and not the abstract syntax tree. In a control-flow graph, nothing follows a return. julia ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Cocci] please help me with a failing match 2018-02-10 13:23 ` Julia Lawall @ 2018-02-10 15:04 ` Robert Larice 2018-02-10 15:15 ` Julia Lawall 0 siblings, 1 reply; 7+ messages in thread From: Robert Larice @ 2018-02-10 15:04 UTC (permalink / raw) To: cocci Julia Lawall <julia.lawall@lip6.fr> writes: > On Sat, 10 Feb 2018, Robert Larice wrote: > >> Dear People, >> >> I'm completely new here. >> >> Attached is a small piece of .c and a .cocci file. >> There is a "return 41;" in both files, commented out. >> If I uncomment this "return 41;" in both files then >> spatch will not match the pieces any more. >> >> Could you please help me to undertand and circumvent this issue ? > > I have not noticed this problem before, but I suspect that it is due to > the fact that Coccinelle is matching the control-flow path and not the > abstract syntax tree. In a control-flow graph, nothing follows a return. > > julia Thank You, I tried to sneak around the problem with a second "rule" which translates "return 42" to "auxiliary(42)". My intention was to first change the source in such a way that the "control-flow" graph does not end at the "return", and then hope that the second (accordingly modified) rule would match. This didn't work, I assume I would have to express the idea of first applying the first rule then to rebuild the control-flow graph then try the second rule. (and finally undo the changes of the first rule in a third rule) I can not force "rebuild" without invoking spatch myself a second time. --- I'm a bit of a maintainer for the "ngspice" project, which has a vast amount of very old files, and lots of semi duplicated stuff often crying for a thourough hair wash, stumbled over this intresting tool, and am tying it for a certain rewrite I'm currently busy with. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Cocci] please help me with a failing match 2018-02-10 15:04 ` Robert Larice @ 2018-02-10 15:15 ` Julia Lawall 2018-02-17 9:06 ` Robert Larice 0 siblings, 1 reply; 7+ messages in thread From: Julia Lawall @ 2018-02-10 15:15 UTC (permalink / raw) To: cocci On Sat, 10 Feb 2018, Robert Larice wrote: > Julia Lawall <julia.lawall@lip6.fr> writes: > > > On Sat, 10 Feb 2018, Robert Larice wrote: > > > >> Dear People, > >> > >> I'm completely new here. > >> > >> Attached is a small piece of .c and a .cocci file. > >> There is a "return 41;" in both files, commented out. > >> If I uncomment this "return 41;" in both files then > >> spatch will not match the pieces any more. > >> > >> Could you please help me to undertand and circumvent this issue ? > > > > I have not noticed this problem before, but I suspect that it is due to > > the fact that Coccinelle is matching the control-flow path and not the > > abstract syntax tree. In a control-flow graph, nothing follows a return. > > > > julia > > Thank You, > I tried to sneak around the problem with a second "rule" which > translates "return 42" to "auxiliary(42)". > My intention was to first change the source in such a way > that the "control-flow" graph does not end at the "return", > and then hope that the second (accordingly modified) rule would > match. > This didn't work, I assume I would have to express the idea of > first applying the first rule > then to rebuild the control-flow graph > then try the second rule. > (and finally undo the changes of the first rule in a third rule) > I can not force "rebuild" without invoking spatch myself a second time. If you change all the returns to something else and then match your pattern, and then change them it should work. > > --- > I'm a bit of a maintainer for the "ngspice" project, which has a vast > amount of very old files, and lots of semi duplicated stuff often crying > for a thourough hair wash, > stumbled over this intresting tool, and am tying it for a certain > rewrite I'm currently busy with. OK,feel free to ask more questions if you run into further issues. julia ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Cocci] please help me with a failing match 2018-02-10 15:15 ` Julia Lawall @ 2018-02-17 9:06 ` Robert Larice 2018-02-17 13:22 ` Julia Lawall 0 siblings, 1 reply; 7+ messages in thread From: Robert Larice @ 2018-02-17 9:06 UTC (permalink / raw) To: cocci Julia Lawall <julia.lawall@lip6.fr> writes: > On Sat, 10 Feb 2018, Robert Larice wrote: > >> Julia Lawall <julia.lawall@lip6.fr> writes: >> >> > On Sat, 10 Feb 2018, Robert Larice wrote: >> > >> >> Dear People, >> >> >> >> I'm completely new here. >> >> >> >> Attached is a small piece of .c and a .cocci file. >> >> There is a "return 41;" in both files, commented out. >> >> If I uncomment this "return 41;" in both files then >> >> spatch will not match the pieces any more. >> >> >> >> Could you please help me to undertand and circumvent this issue ? >> > >> > I have not noticed this problem before, but I suspect that it is due to >> > the fact that Coccinelle is matching the control-flow path and not the >> > abstract syntax tree. In a control-flow graph, nothing follows a return. >> > >> > julia >> >> Thank You, >> I tried to sneak around the problem with a second "rule" which >> translates "return 42" to "auxiliary(42)". >> My intention was to first change the source in such a way >> that the "control-flow" graph does not end at the "return", >> and then hope that the second (accordingly modified) rule would >> match. >> This didn't work, I assume I would have to express the idea of >> first applying the first rule >> then to rebuild the control-flow graph >> then try the second rule. >> (and finally undo the changes of the first rule in a third rule) >> I can not force "rebuild" without invoking spatch myself a second time. > > If you change all the returns to something else and then match your > pattern, and then change them it should work. > >> >> --- >> I'm a bit of a maintainer for the "ngspice" project, which has a vast >> amount of very old files, and lots of semi duplicated stuff often crying >> for a thourough hair wash, >> stumbled over this intresting tool, and am tying it for a certain >> rewrite I'm currently busy with. > > OK,feel free to ask more questions if you run into further issues. > > julia Hello, Thank you for your help. I've four or five .cocci files now which do the job at hand for ngspice quite well. The rewrite of return to something else with two times invocation of spatch did work. Then I found another simpler way. So thats done. Playing around, trying to better understand what it means to have more than one rule, their interaction etc .. I came to the attached example. Here I have basically tried to remove the whole body of a function iff the function matches two other @rules@ It seems to work if I use the '*' notation, but doesnt if I use '+/-' Can you give me a hint which helps me to understand this ? Regards, Robert -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ex4.cocci URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180217/12a80ed1/attachment.ksh> -------------- next part -------------- A non-text attachment was scrubbed... Name: ex4.c Type: text/x-csrc Size: 150 bytes Desc: not available URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20180217/12a80ed1/attachment.bin> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Cocci] please help me with a failing match 2018-02-17 9:06 ` Robert Larice @ 2018-02-17 13:22 ` Julia Lawall 2018-02-17 14:05 ` Robert Larice 0 siblings, 1 reply; 7+ messages in thread From: Julia Lawall @ 2018-02-17 13:22 UTC (permalink / raw) To: cocci On Sat, 17 Feb 2018, Robert Larice wrote: > Julia Lawall <julia.lawall@lip6.fr> writes: > > > On Sat, 10 Feb 2018, Robert Larice wrote: > > > >> Julia Lawall <julia.lawall@lip6.fr> writes: > >> > >> > On Sat, 10 Feb 2018, Robert Larice wrote: > >> > > >> >> Dear People, > >> >> > >> >> I'm completely new here. > >> >> > >> >> Attached is a small piece of .c and a .cocci file. > >> >> There is a "return 41;" in both files, commented out. > >> >> If I uncomment this "return 41;" in both files then > >> >> spatch will not match the pieces any more. > >> >> > >> >> Could you please help me to undertand and circumvent this issue ? > >> > > >> > I have not noticed this problem before, but I suspect that it is due to > >> > the fact that Coccinelle is matching the control-flow path and not the > >> > abstract syntax tree. In a control-flow graph, nothing follows a return. > >> > > >> > julia > >> > >> Thank You, > >> I tried to sneak around the problem with a second "rule" which > >> translates "return 42" to "auxiliary(42)". > >> My intention was to first change the source in such a way > >> that the "control-flow" graph does not end at the "return", > >> and then hope that the second (accordingly modified) rule would > >> match. > >> This didn't work, I assume I would have to express the idea of > >> first applying the first rule > >> then to rebuild the control-flow graph > >> then try the second rule. > >> (and finally undo the changes of the first rule in a third rule) > >> I can not force "rebuild" without invoking spatch myself a second time. > > > > If you change all the returns to something else and then match your > > pattern, and then change them it should work. > > > >> > >> --- > >> I'm a bit of a maintainer for the "ngspice" project, which has a vast > >> amount of very old files, and lots of semi duplicated stuff often crying > >> for a thourough hair wash, > >> stumbled over this intresting tool, and am tying it for a certain > >> rewrite I'm currently busy with. > > > > OK,feel free to ask more questions if you run into further issues. > > > > julia > > Hello, > > Thank you for your help. I've four or five .cocci files now which > do the job at hand for ngspice quite well. The rewrite of return > to something else with two times invocation of spatch did work. > Then I found another simpler way. So thats done. > > Playing around, trying to better understand what it means > to have more than one rule, their interaction etc .. > I came to the attached example. > Here I have basically tried to remove the whole body of a function > iff the function matches two other @rules@ > It seems to work if I use the '*' notation, but doesnt if I use > '+/-' > Can you give me a hint which helps me to understand this ? For -+, Coccinelle requires that all control-flow paths from the starting point of the match match the complete rule. So for example a() ... b() would match the following: a(); if (x) b(); else b(); For *, it only requires the existence of such a path. If you have a -+ somewhere in the semantic patch, then all rules use the forall semantics. If you have a * somewhere in the semantic patch, then all rules use the exists semantics. In your rule r2, you have ... Label: but this label is not reached on the execution path that ends in return 1. When you have -+ somewhere in the semantic patch this rule is not satisfied. If you want to change the default for a rule, you can add exists for forall to the rule header, or put when exists or when forall on the ... julia ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Cocci] please help me with a failing match 2018-02-17 13:22 ` Julia Lawall @ 2018-02-17 14:05 ` Robert Larice 0 siblings, 0 replies; 7+ messages in thread From: Robert Larice @ 2018-02-17 14:05 UTC (permalink / raw) To: cocci Julia Lawall <julia.lawall@lip6.fr> writes: > On Sat, 17 Feb 2018, Robert Larice wrote: > >> Julia Lawall <julia.lawall@lip6.fr> writes: >> >> > On Sat, 10 Feb 2018, Robert Larice wrote: >> > >> >> Julia Lawall <julia.lawall@lip6.fr> writes: >> >> >> >> > On Sat, 10 Feb 2018, Robert Larice wrote: >> >> > >> >> >> Dear People, >> >> >> >> >> >> I'm completely new here. >> >> >> >> >> >> Attached is a small piece of .c and a .cocci file. >> >> >> There is a "return 41;" in both files, commented out. >> >> >> If I uncomment this "return 41;" in both files then >> >> >> spatch will not match the pieces any more. >> >> >> >> >> >> Could you please help me to undertand and circumvent this issue ? >> >> > >> >> > I have not noticed this problem before, but I suspect that it is due to >> >> > the fact that Coccinelle is matching the control-flow path and not the >> >> > abstract syntax tree. In a control-flow graph, nothing follows a return. >> >> > >> >> > julia >> >> >> >> Thank You, >> >> I tried to sneak around the problem with a second "rule" which >> >> translates "return 42" to "auxiliary(42)". >> >> My intention was to first change the source in such a way >> >> that the "control-flow" graph does not end at the "return", >> >> and then hope that the second (accordingly modified) rule would >> >> match. >> >> This didn't work, I assume I would have to express the idea of >> >> first applying the first rule >> >> then to rebuild the control-flow graph >> >> then try the second rule. >> >> (and finally undo the changes of the first rule in a third rule) >> >> I can not force "rebuild" without invoking spatch myself a second time. >> > >> > If you change all the returns to something else and then match your >> > pattern, and then change them it should work. >> > >> >> >> >> --- >> >> I'm a bit of a maintainer for the "ngspice" project, which has a vast >> >> amount of very old files, and lots of semi duplicated stuff often crying >> >> for a thourough hair wash, >> >> stumbled over this intresting tool, and am tying it for a certain >> >> rewrite I'm currently busy with. >> > >> > OK,feel free to ask more questions if you run into further issues. >> > >> > julia >> >> Hello, >> >> Thank you for your help. I've four or five .cocci files now which >> do the job at hand for ngspice quite well. The rewrite of return >> to something else with two times invocation of spatch did work. >> Then I found another simpler way. So thats done. >> >> Playing around, trying to better understand what it means >> to have more than one rule, their interaction etc .. >> I came to the attached example. >> Here I have basically tried to remove the whole body of a function >> iff the function matches two other @rules@ >> It seems to work if I use the '*' notation, but doesnt if I use >> '+/-' >> Can you give me a hint which helps me to understand this ? > > For -+, Coccinelle requires that all control-flow paths from the starting > point of the match match the complete rule. So for example a() ... b() > would match the following: > > a(); > if (x) > b(); > else b(); > > For *, it only requires the existence of such a path. > > If you have a -+ somewhere in the semantic patch, then all rules use the > forall semantics. If you have a * somewhere in the semantic patch, then > all rules use the exists semantics. > > In your rule r2, you have ... Label: but this label is not reached on the > execution path that ends in return 1. When you have -+ somewhere in the > semantic patch this rule is not satisfied. > > If you want to change the default for a rule, you can add exists for > forall to the rule header, or put when exists or when forall on the ... > > julia Thank You very much, The behaviour, and what I have to do to fix it, is perfectly clear now, Regards, Robert ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-02-17 14:05 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-10 12:12 [Cocci] please help me with a failing match Robert Larice 2018-02-10 13:23 ` Julia Lawall 2018-02-10 15:04 ` Robert Larice 2018-02-10 15:15 ` Julia Lawall 2018-02-17 9:06 ` Robert Larice 2018-02-17 13:22 ` Julia Lawall 2018-02-17 14:05 ` Robert Larice
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.