@r forall@
position p;
local idexpression x;
I would also like to consider that a return value can be assigned to a global
variable.
OK, no problem. Just change local idexpression to identifier.
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?
An isomorphism takes care of it, because S2 is not used elsewhere.
How does the conditional operator fit into the picture?
http://en.wikipedia.org/wiki/%3F:#C
You can add whatever when clauses you want, I just made an example that
shows the general idea.
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)?
I guess you aren't interested in searching for the case where it is used
directly? Because then it is used, and there is no error mesage to give.
Which approach would you like to suggest for the control flow constructs
"for" and "[do] while"?
I have no idea what you mean here. Do you want to put them in the when
clauses? If so, go ahead.
?x = e
What is the purpose of this SmPL singleton here?
To stop the matching if there is a reassignment of x, if there is one
(indicated by ?).
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.
There is no reason why a function would be more or less likely to do
something useful with the values.
julia
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)
