Hacker News Reader

Comment by belovedeagle | Hacker News Reader

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.

View on HN

Even 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.

There is no way of fully detecting it, because of function pointers.

This 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.

Sorry, how is this O(m*n)?

Hmmm... 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).

> "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.

Reply on news.ycombinator.com