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
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci
