*Re: [Cocci] Challenges around asterisk usage in SmPL code
2019-08-25 9:11 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring
@ 2019-08-25 9:45 ` Julia Lawall
2019-08-25 10:22 ` Markus Elfring
` (2 more replies)0 siblings, 3 replies; 15+ messages in thread
From: Julia Lawall @ 2019-08-25 9:45 UTC (permalink / raw)
To: Markus Elfring; +Cc: Coccinelle
On Sun, 25 Aug 2019, Markus Elfring wrote:
> >> Does this SmPL construct help to restrict a source code search element
> >> (while using SmPL ellipses) to a single statement for the shown analysis example?
> >
> > Yes.
>
> I get a parse error also for the following SmPL script variant.
>
> @check@
> expression x;
> statement es;
> @@
> *if ( \( !(x) \| x == NULL \) )
> * <+... *(x) ...+>;
> else
> es
>
>
> Can it be avoided to express assignment variations explicitly?
I don't know what you are trying to do. Previously, you had the beginning
of an assignment before the ... I suggested to replace the ... before and
after the *(x) by <+... ...+>. Strangely you have deleted the assignment
part as well.
Your code line with the <+... ...+> ends with a ;. So the <+... ...+>
must match an expression (which could be an assignment). But due to
parsing priorities, <+... ...+> that is unknown is parsed as a statement.
So the ; causes a parse error. To force the <+... ...+> to be parsed as
an expression, you have to surround it with (). An isomorphism will
normally cause the case without the parentheses to be considered as well.
None of this has anything to do with unary operators.
julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci^permalinkrawreply [flat|nested] 15+ messages in thread

*Re: [Cocci] Challenges around asterisk usage in SmPL code
2019-08-25 9:45 ` Julia Lawall@ 2019-08-25 10:22 ` Markus Elfring
2019-08-25 13:13 ` [Cocci] Checking information from “--parse-cocci” Markus Elfring
2019-08-25 17:34 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring
2019-08-26 17:26 ` [Cocci] Checking null pointer handling with SmPL Markus Elfring
2 siblings, 1 reply; 15+ messages in thread
From: Markus Elfring @ 2019-08-25 10:22 UTC (permalink / raw)
To: Julia Lawall; +Cc: Coccinelle
>> @check@
>> expression x;
>> statement es;
>> @@
>> *if ( \( !(x) \| x == NULL \) )
>> * <+... *(x) ...+>;
>> else
>> es
>>
>>
>> Can it be avoided to express assignment variations explicitly?
>
> I don't know what you are trying to do.
Can you get the impression that I am trying also to achieve something
around the detection of null pointer usage?
> Previously, you had the beginning of an assignment before the ...
> I suggested to replace the ... before and after the *(x) by <+... ...+>.
This variant gets accepted by the Coccinelle software.
> Strangely you have deleted the assignment part as well.
I became curious if such an approach should also work.
> Your code line with the <+... ...+> ends with a ;.
Yes - for this test.
> So the <+... ...+> must match an expression (which could be an assignment).
This can be appropriate.
> But due to parsing priorities, <+... ...+> that is unknown is parsed as a statement.
> So the ; causes a parse error. To force the <+... ...+> to be parsed as
> an expression, you have to surround it with (). An isomorphism will
> normally cause the case without the parentheses to be considered as well.
Thanks for this explanation.
> None of this has anything to do with unary operators.
This view is reasonable.
I just put a search pattern with an asterisk into this SmPL construct.
Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci^permalinkrawreply [flat|nested] 15+ messages in thread

*Re: [Cocci] Checking information from “--parse-cocci”
2019-08-25 10:22 ` Markus Elfring@ 2019-08-25 13:13 ` Markus Elfring
[not found] ` <alpine.DEB.2.21.1908252118210.2801@hadrien>
0 siblings, 1 reply; 15+ messages in thread
From: Markus Elfring @ 2019-08-25 13:13 UTC (permalink / raw)
To: Julia Lawall; +Cc: Coccinelle
>> To force the <+... ...+> to be parsed as an expression, you have to surround it with ().
I was unused to this technical detail.
Will such information become more helpful also for a better software documentation?
I adjusted my evolving search pattern a bit more.
I looked at the output from the command “spatch --parse-cocci …” again.
I find a display like the following questionable then.
“…
)) eselse {
... WHEN any WHEN != x = y;
…”
Would another delimiter be better in the output like “)) es else {” here?
Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci^permalinkrawreply [flat|nested] 15+ messages in thread