The solution is not to actually perform any transformations on the
subexpressions a and b. The example works fine with the following
semantic patch:
@ oper_add @
expression a, b;
@@
- oper_add(
a
- ,
+ +
b
- )
The only small unfortunate bit is that the pretty printing is not very
nice. It doesn't realize that + is a binary operator, and so there is no
space before it, although there is a space after it. It should be
possible to fix this.
julia
On Wed, 9 Mar 2011, Dan McGee wrote:
> I've included a test case here for what I am trying to do- help much
> appreciated. How can I get it to not barf on recursively nested
> expressions? The expected output here would be "b = 1 + 2 + 3;".
>
> -Dan
>
> ** operator.c:
> #define oper_add(__a, __b) ((__a) + (__b))
>
> int main(int argc, char *argv[])
> {
> int a, b;
> // this works...
> a = oper_add(2, 3);
> // but this doesn't.
> b = oper_add(1, oper_add(2, 3));
> return(0);
> }
>
>
> ** operator.cocci:
> @ oper_add @
> expression a, b;
> @@
> - oper_add(a, b)
> + a + b
>
>
> ** output:
> $ spatch -sp_file operator.cocci operator.c
> init_defs_builtins: /usr/share/coccinelle/standard.h
> HANDLING: operator.c
>
> previous modification:
> MINUS
> According to environment 2:
> oper_add.b -> 3
> oper_add.a -> 2
>
> current modification:
> MINUS
> According to environment 2:
> oper_add.b -> oper_add(2, 3)
> oper_add.a -> 1
>
> Fatal error: exception Failure("oper_add: already tagged token:
> C code context
> File "operator.c", line 9, column 26, charpos = 179
> around = '2', whole content = b = oper_add(1, oper_add(2, 3));")
> _______________________________________________
> Cocci mailing list
> [email protected]
> http://lists.diku.dk/mailman/listinfo/cocci
> (Web access from inside DIKUs LAN only)
>
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
