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] 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. I find the handling of higher level data storage relevant and useful also for such a software test. > If you believe that there is a problem with the semantic patch, > you have to make a small version that illustrates the problem. My SmPL script example seems to work as expected (in principle) if I omit the else branch from the SmPL rules “find1” and “check1”. 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
> If you want something done, please do it yourself.
I hope that another clarification can be achieved also for the software
behaviour of the following source code analysis approach.
@initialize:python@
@@
import sqlalchemy, sys
sys.stderr.write("\n".join(["Using SQLAlchemy version:",
sqlalchemy.__version__]))
sys.stderr.write("\n")
from sqlalchemy import create_engine, Column, Integer, String
engine = create_engine("sqlite:///:memory:", echo = False)
from sqlalchemy.ext.declarative import declarative_base
base = declarative_base()
class pair(base):
__tablename__ = "pairs"
function = Column(String, primary_key = True)
source_file = Column(String, primary_key = True)
line = Column(Integer, primary_key = True)
column = Column(Integer, primary_key = True)
action = Column(String)
check = Column(String)
from sqlalchemy.orm import sessionmaker
configured_session = sessionmaker(bind = engine)
session = configured_session()
base.metadata.create_all(engine)
def store_positions(places, check_in, action_in):
"""Add source code positions to an internal table."""
for place in places:
entry = pair(function = place.current_element,
source_file = place.file,
line = place.line,
column = int(place.column) + 1,
action = action_in,
check = check_in
)
session.add(entry)
@find1@
expression action, e;
position p;
statement is, es;
@@
e = action(...);
if@p (<+... e ...+>)
is
else
es
@check1@
expression check;
position find1.p;
statement find1.is, find1.es;
@@
if@p (check)
is
else
es
@script:python collection1@
c << check1.check;
action << find1.action;
places << find1.p;
@@
store_positions(places, c, action)
@finalize:python@
@@
session.commit()
from sqlalchemy import func
entries = session.query(func.count("*")).select_from(pair).scalar()
if entries > 0:
delimiter = "|"
sys.stdout.write(delimiter.join(['action',
'check',
'"source file"',
"line",
"column"
]))
sys.stdout.write("\r\n")
for action, \
check, \
file, \
line, \
column in session.query(pair.action,
pair.check,
pair.source_file,
pair.line,
pair.column
).order_by(pair.action,
pair.check,
pair.source_file,
pair.line,
pair.column
):
sys.stdout.write(delimiter.join([action,
check,
file,
str(line),
str(column)
]))
sys.stdout.write("\r\n")
else:
sys.stderr.write("No result for this analysis!\n")
elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci
list_condition_checks_after_function_calls2.cocci
…
warning: iso drop_else does not match the code below on line 55
if@p (check) iselse es
…
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.10
HANDLING: drivers/gpu/drm/mcde/mcde_drv.c
No result for this analysis!
Will any software development possibilities become interesting here?
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
>> Would you like to display statistics around the distribution of condition >> checks after function calls (with help of the semantic patch language)? > > I'm working on other things. Thanks for your feedback. > If you want something done, please do it yourself. I assumed that you (or other contributors) could help to reduce my concerns also around limited data processing resources for challenging source code analysis approaches. 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 Sat, 11 Apr 2020, Markus Elfring wrote: > > Maybe you can just take inspiration from this paper: > > > > https://pages.lip6.fr/Julia.Lawall/dsn09.pdf > > I got another idea which can be related to information from the section > “Case Study: Inconsistent Error Checks” in your document “WYSIWIB: > A Declarative Approach to Finding API Protocols and Bugs in Linux Code”. > A key aspect is the knowledge about failure predicates for functions > from programming interfaces. > How do you think about to improve the knowledge by the means of advanced > source code analysis? > > I got the impression that such analysis attempts can become especially > challenging if data processing resources might occasionally be too limited > for a growing code base like Linux software. > Would you like to display statistics around the distribution of condition > checks after function calls (with help of the semantic patch language)? I'm working on other things. If you want something done, please do it yourself. julia___ 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
> Maybe you can just take inspiration from this paper: > > https://pages.lip6.fr/Julia.Lawall/dsn09.pdf I got another idea which can be related to information from the section “Case Study: Inconsistent Error Checks” in your document “WYSIWIB: A Declarative Approach to Finding API Protocols and Bugs in Linux Code”. A key aspect is the knowledge about failure predicates for functions from programming interfaces. How do you think about to improve the knowledge by the means of advanced source code analysis? I got the impression that such analysis attempts can become especially challenging if data processing resources might occasionally be too limited for a growing code base like Linux software. Would you like to display statistics around the distribution of condition checks after function calls (with help of the semantic patch language)? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
