3 ms·
Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments.
by belovedeagle 11y ago
Of course, to "really" solve this problem you'd have to recognize "mutually unused" arguments: foo(a,b) calls foo(b,a) and doesn't otherwise use the arguments. But foo(x,a) which uses x and calls foo(a,x) uses both. Not difficult to solve, and a few seconds' thought puts it in O(m*n) with m recursive calls and n parameters... but probably not worth the trouble.
- chaosemer 11y agoEven worse, foo(a,b) could call bar(a,b,c) which calls foo(b,a), all without otherwise looking at a or b. This could get really bad really fast. But that feels like the wrong way to analyze this. Even though a full solution isn't practical, a limited one may be.
- nocsaer1 11y agoThere is no way of fully detecting it, because of function pointers.
- vikiomega9 11y agoSorry, how is this O(m*n)?
- belovedeagle 11y agoHmmm... represent the parameters as nodes in a directed graph. For each of m recursive call sites, process each of n parameters and add edges from formal parameter name to passed argument (i.e., if we have signature foo(a,b,c) and recursive call foo(c,b,c), add edge a->c; self-edges are unimportant). This step is O(mn). Then, assuming we already know what parameters are used outside of function calls, flood-fill the graph from those nodes; this is O(n). O(mn+n)=O(m*n).
- vikiomega9 11y ago> "Then, assuming we already know what parameters are used outside of function calls" This is something that needs to be done, I guess my confusion was that you already have this information and that should be sufficient to finding the unused parametres.
- anon4 11y agoThis really is looking like a job for a static code analyzer. I'm all for the compiler emitting warnings as much as it can, but I also want it to compile my code very fast... I think the right approach here is to run slow code analysis tools frequently, but less frequently than compiles.