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