I'm not sure how you mean to combine these.
Both use cases need to be checked eventually.
The return value is used in neither 1 nor 2?
A return value is ignored if it is not used in both situations, isn't it?
In your solution, there is not enough connection between the rules.
Thanks for your explanation.
identifier y is just a name. It can match anywhere in the program, not necessarily in the places that follow your assignment.
I admit that I am still not as familiar with the key words of the semantic patch language as you.
Does your following approach consider the involved scopes better in the source code?
@r forall@ position p; local idexpression x;
I would also like to consider that a return value can be assigned to a global variable.
expression f,g,e; statement S1,S2; @@ x@p = f(...); ... when != if (<+...x...+>) S1 else S2
How do you want to deal with such conditions where the else clause is omitted? How does the conditional operator fit into the picture? http://en.wikipedia.org/wiki/%3F:#C
when != g(...,(<+...x...+>),...)
Is an additional SmPL wording needed for the case if a function's value is used directly (without a previous variable assignment)?
Which approach would you like to suggest for the control flow constructs "for" and "[do] while"?
?x = e
What is the purpose of this SmPL singleton here?
I'm not sure what you want to do with macros. I guess a macro call could look like a use of x in an argument, but the macro could do something else. But I'm not sure why you would want to distinguish this from a function call that does something else with the value.
Macro uses can syntactically look like functions calls. A function should perform something useful with the passed values after its compilation.
When you pass a value to a function, you don't know if it is going to test it.
That is true. - I guess that the search for unused function parameters is another use case for static source code analysis, isn't it? ;-)
(C compilers can warn about this situation already.) Regards, Markus _______________________________________________ Cocci mailing list [email protected] http://lists.diku.dk/mailman/listinfo/cocci (Web access from inside DIKUs LAN only)
