Re: Possible code defects: macros and precedence

[Joe Perches]

On Tue, 2016-09-20 at 15:14 +0200, Julia Lawall wrote:
> The semantic patch below finds a binary operator in a macro and a binary
> operator in the use of the macro, and checks if the priority of the
> operator in the macro is higher (lower number) than the priority of the
> operator in the use.  If this is the case, it adds parentheses in the use,
> which is not what one wants, but serves to show where the problem is.
> 
> It doesn't turn up anything, except an occurrence of (u32)-1, which
> Coccinelle parses as a subtraction, due to not having any nearby evidence
> that u32 is a type.
> 
> I didn't make any special effort on the include files, which means that
> only local include files and ones with the same name as the C file are
> taken into account.  I can try with more aggressive include options.
> 
> This only works with the github version of Coccinelle, as it required
> quite a lot of improvement to the treatmern of #define.
> 
> julia
> 
> @initialize:ocaml@
> @@
> 
> let binoptbl =
>     [("*",3);("/",3);("%",3);

Shouldn't bitwise negation (~) and not (!) be added at 3?

	("~",3);("!",3);
 
>       ("+",4);("-",4);
>       ("<<",5);(">>",5);
>       ("<",6);(">",6);("<=",6);(">=",6);
>       ("==",7);("!=",7);
>       ("&",8);
>       ("^",9);
>       ("|",10);
>       ("&&",11);
>       ("||",12)]
> 
> @r@
> identifier i,j;
> identifier list[n] is;
> binary operator b;
> expression e;
> @@
> 
> #define i(is,j,...) (<+... \(j b e \| e b j\) ...+>)
> 
> @s@
> identifier r.i;
> expression list[r.n] es;
> binary operator b1;
> expression e1,e2;
> position p;
> @@
> 
> >  i@p(es,e1 b1 e2,...)
> 
> @script:ocaml@
> _p << s.p;
> b << r.b;
> b1 << s.b1;
> @@
> 
> try
>   let p1 = List.assoc b binoptbl in
>   let p2 = List.assoc b1 binoptbl in
>   if p1 >= p2 then Coccilib.include_match false
> with Not_found -> ()
> 
> @@
> identifier r.i;
> expression list[r.n] es;
> expression e;
> position s.p;
> @@
> 
> i@p(es,
> +(
> e
> +)
> ,...)
>