Re: [Cocci] More support for SmPL data processing with databases?
>> I hope that it can become easier to clarify where unexpected duplicate keys >> would occur as in my test approach. > > Use --debug and just print out the infomation rather than putting is in > your database. We have got different views around this logging approach. > With the database you add complexity for nothing. I disagree to this view. Database software usually provides some helpful functionality, doesn't it? The mentioned programming interface quickly pointed an unique constraint violation out. Now I am looking again for possible solutions. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] More support for SmPL data processing with databases?
> I think that your issue about something matching or not has nothing to do > with the database code, and you could easily remove it for the purposes of > reporting a concern with Coccinelle. Software evolution can be continued also together with your constructive feedback. I adapted another SmPL script according to a recent information. https://lore.kernel.org/cocci/17a4592b-92bd-e4c9-8481-7d46616cb...@web.de/T/#m4f59721d2011ac4ded602f2e63e0c63f22a15fa9 https://systeme.lip6.fr/pipermail/cocci/2020-April/007133.html It can become more interesting to increase also the application of SmPL conjunctions like the following. @find@ expression action, check, result; position p; statement is, es; @@ result = action(...); if@p ( ( <+... result ...+> & check ) ) is else es Now I stumble on corresponding software development challenges. elfring@Sonne:~/Projekte/Linux/next-patched> spatch ~/Projekte/Coccinelle/janitor/list_condition_checks_after_function_calls2.cocci drivers/gpu/drm/mcde/mcde_drv.c … Using SQLAlchemy version: 1.3.15 … sqlalchemy.exc.IntegrityError: (sqlite3.IntegrityError) UNIQUE constraint failed: pairs.function, pairs.source_file, pairs.line, pairs.column [SQL: INSERT INTO pairs (function, source_file, line, "column", action, "check") VALUES (?, ?, ?, ?, ?, ?)] … I hope that it can become easier to clarify where unexpected duplicate keys would occur as in my test approach. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
>> Can the matched source code from the construct “<+... e ...+>” be assigned >> to a metavariable like “check”? > > ( > <+... e ...+> > & > check > ) Did I just stumble on incomplete knowledge for the safe application of the conjunction functionality with the semantic patch language? It seems that some source code search approaches can be improved in such a way. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
On Sun, 12 Apr 2020, Markus Elfring wrote: > @display2@ > expression check; > position display1.p; > statement display1.is, display1.es; > >>> > >>> The problem is that you inherit es. Since you inherit it, Coccinelle > >>> considers that its presence is important, and so the isomorphism will not > >>> eliminate it. > >> > >> Thanks for your explanation of such consequences by the metavariable > >> inheritance. > > It seems that the specification of the inheritance for the metavariable “es” > can be (temporarily) omitted as a workaround. > > > >>> It is sufficient to make another pattern for the case with no else. > >> > >> I might stumble on another software design conflict (or the need > >> for corresponding software extensions). > >> > >> I tried the specification of the SmPL rule “display2” out because I wanted > >> to determine the source code which was matched by the SmPL nest construct > >> in the SmPL rule “display1”. > >> The specification of a SmPL disjunction in the first rule would trigger > >> other known development difficulties (or open issues), wouldn't it? > > > > No idea. > > I would prefer to find the shown statement combination by a single SmPL rule. > Can the matched source code from the construct “<+... e ...+>” be assigned > to a metavariable like “check”? ( <+... e ...+> & check ) julia > > Regards, > Markus >___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
@display2@ expression check; position display1.p; statement display1.is, display1.es; >>> >>> The problem is that you inherit es. Since you inherit it, Coccinelle >>> considers that its presence is important, and so the isomorphism will not >>> eliminate it. >> >> Thanks for your explanation of such consequences by the metavariable >> inheritance. It seems that the specification of the inheritance for the metavariable “es” can be (temporarily) omitted as a workaround. >>> It is sufficient to make another pattern for the case with no else. >> >> I might stumble on another software design conflict (or the need >> for corresponding software extensions). >> >> I tried the specification of the SmPL rule “display2” out because I wanted >> to determine the source code which was matched by the SmPL nest construct >> in the SmPL rule “display1”. >> The specification of a SmPL disjunction in the first rule would trigger >> other known development difficulties (or open issues), wouldn't it? > > No idea. I would prefer to find the shown statement combination by a single SmPL rule. Can the matched source code from the construct “<+... e ...+>” be assigned to a metavariable like “check”? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
>> @display1@ >> expression action, e; >> position p; >> statement is, es; >> @@ >> *e = action(...); >> if@p (<+... e ...+>) >> is >> else >> es >> >> @display2@ >> expression check; >> position display1.p; >> statement display1.is, display1.es; > > The problem is that you inherit es. Since you inherit it, Coccinelle > considers that its presence is important, and so the isomorphism will not > eliminate it. Thanks for your explanation of such consequences by the metavariable inheritance. > It is sufficient to make another pattern for the case with no else. I might stumble on another software design conflict (or the need for corresponding software extensions). I tried the specification of the SmPL rule “display2” out because I wanted to determine the source code which was matched by the SmPL nest construct in the SmPL rule “display1”. The specification of a SmPL disjunction in the first rule would trigger other known development difficulties (or open issues), wouldn't it? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
On Sun, 12 Apr 2020, Markus Elfring wrote: > >> I hope that another clarification can be achieved also for the software > >> behaviour of the following source code analysis approach. > > > > I don't run code that involves databases. If you believe that there is a > > problem with the semantic patch, you have to make a small version that > > illustrates the problem. > > Would you find the test result easier to clarify for the following > SmPL script example? > > > @display1@ > expression action, e; > position p; > statement is, es; > @@ > *e = action(...); > if@p (<+... e ...+>) > is > else > es > > @display2@ > expression check; > position display1.p; > statement display1.is, display1.es; The problem is that you inherit es. Since you inherit it, Coccinelle considers that its presence is important, and so the isomorphism will not eliminate it. It is sufficient to make another pattern for the case with no else. julia > @@ > *if@p (check) > is > else > es > > > elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci > show_condition_checks_after_function_calls2.cocci > … > warning: iso drop_else does not match the code below on line 17 > if@p (check) iselse es > … > > > Will any software improvements become interesting for such an use case? > > Regards, > Markus >___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Reporting variations of condition checks according to function calls
>> I hope that another clarification can be achieved also for the software >> behaviour of the following source code analysis approach. > > I don't run code that involves databases. If you believe that there is a > problem with the semantic patch, you have to make a small version that > illustrates the problem. Would you find the test result easier to clarify for the following SmPL script example? @display1@ expression action, e; position p; statement is, es; @@ *e = action(...); if@p (<+... e ...+>) is else es @display2@ expression check; position display1.p; statement display1.is, display1.es; @@ *if@p (check) is else es elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_condition_checks_after_function_calls2.cocci … warning: iso drop_else does not match the code below on line 17 if@p (check) iselse es … Will any software improvements become interesting for such an use case? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking the application of the SmPL isomorphism “drop_else”
> I noticed that there was a report about an isomorphism not applying. I hoped for another clarification also for the message “warning: iso drop_else does not match the code below on line 55” (and the corresponding debug display). > That issurely the problem. So you have to figure out why it does not apply. > There is an isomorphism that drops else's in ifs, but that only applies if > the else is a metavariable that is not used elsewhere. I am looking for further improvements in this software area. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] More support for SmPL data processing with databases?
> I think that your issue about something matching or not has nothing to do > with the database code, Such a view can be partly appropriate. > and you could easily remove it I hope that the understanding of the presented SmPL code example could also be sufficient in the way that the data processing for the SmPL rules “find1” and “check1” will need another bit of clarification. > for the purposes of reporting a concern with Coccinelle. Another code variant can eventually be clarified a bit later. Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] More support for SmPL data processing with databases?
On Sun, 12 Apr 2020, Markus Elfring wrote: > >> I hope that another clarification can be achieved also for the software > >> behaviour of the following source code analysis approach. > > > > I don't run code that involves databases. > > Can the situation evolve in a way so that this programming interface > will become better supported together with programming languages > and development tools you are more familiar with (so far)? I think that your issue about something matching or not has nothing to do with the database code, and you could easily remove it for the purposes of reporting a concern with Coccinelle. julia > > Regards, > Markus > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] More support for SmPL data processing with databases?
>> I hope that another clarification can be achieved also for the software >> behaviour of the following source code analysis approach. > > I don't run code that involves databases. Can the situation evolve in a way so that this programming interface will become better supported together with programming languages and development tools you are more familiar with (so far)? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
