>> 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
>> 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
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
@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
>> @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.
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
>> 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
>
> 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
> 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
12 matches
Mail list logo
