> I think that you just want to disable the isomorphism. Put disable neg_if
> in the initial @@ of your rule.
>>
>> Will a need evolve to switch isomorphisms completely off for safer
>> (and efficient) analysis of original source code?
Will the corresponding system configuration get any
On Mon, 13 Apr 2020, Markus Elfring wrote:
> >> I would find it nice to explain the different software behaviour for the
> >> mentioned
> >> SmPL code variants
> >
> > Run spatch -parse-cocci and you will easily see. The if stays in the same
> > place. When the isomorphism exchanges the
>> I would find it nice to explain the different software behaviour for the
>> mentioned
>> SmPL code variants
>
> Run spatch -parse-cocci and you will easily see. The if stays in the same
> place. When the isomorphism exchanges the branches, the condition gets
> negated, so in one case you get
On Mon, 13 Apr 2020, Markus Elfring wrote:
> >>> Maybe you consider the following results to be a problem:
> >>>
> >>> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> >>> platform_get_irq irq
>>> Maybe you consider the following results to be a problem:
>>>
>>> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
>>> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
>>> platform_get_irq irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
>>>
On Mon, 13 Apr 2020, Markus Elfring wrote:
> > Maybe you consider the following results to be a problem:
> >
> > kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> > kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> > platform_get_irq irq [("mcde_probe", 2,
> Maybe you consider the following results to be a problem:
>
> kzalloc mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> kzalloc ! mcde [("mcde_probe", 2, 0, 198, 1, "m.c", 16, 1, 16, 3)]
> platform_get_irq irq [("mcde_probe", 2, 0, 198, 1, "m.c", 97, 1, 97, 3)]
> platform_get_irq ! irq
> @script:ocaml@
> action << find.action;
> check << find.check;
> p << find.p;
> @@
> Printf.printf "%s %s %s\n" action check (Dumper.dump p)
>
> On the code you provided whichis unfortunately much too long to include in
> a message
I found my code examples short enough.
> and that you could
I tried the following semantic patches:
@find@
expression action, check, result;
position p;
statement is, es;
@@
result = action(...);
if (
( <+... result ...+>
& check@p
) )
is
else
es
@script:ocaml@
action << find.action;
check << find.check;
p << find.p;
@@
Printf.printf "%s
>> How will the application of SmPL conjunctions evolve further?
>
> I really have no idea what you are talking about.
I suggest to take another look at affected implementation details.
> Make one single mail that contains all of the semantic patch variants
> that you want to have considered
>> Do I present another advanced use case for the application of known software
>> tools?
>
> No.
Such a view can be also interesting.
> The faults in linux paper (work done 10 years ago) uses a database as well.
Thanks for this background information.
How will the software evolve further in
> Now you have the two scripts, which is good, but you haven't included the
> test data that causes the problem. Please make one mail that includes
> everything.
I find that I provided relevant data already.
https://systeme.lip6.fr/pipermail/cocci/2020-April/007135.html
>>> The database itself doesn't bring any value.
>>
>> Another unique constraint violation was noticed by using such technology.
>
> It's an accident.
This might be. - I got into the development mood to publish patches
for a few source files of Linux modules according to another search approach.
>> I observe that the following SmPL code variant can result also in
>> a significant difference.
>>
>> @find@
>> expression action, check, result;
>> position p;
>> statement is, es;
>> @@
>> result = action(...);
>> if (
>> ( <+... result ...+>
>> & check@p
>> ) )
>> is
>> else
>>
> I hope that it can become easier to clarify where unexpected duplicate keys
> would occur as in my test approach.
There is the possibility to apply information according to a clarification
request on a topic like “Checking the handling of unique keys/indexes”
from 2014-12-20.
>> 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
> 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
> 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
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
>> 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
20 matches
Mail list logo
