[Discuss] finding dead code in C projects

[gaf at blu.org (Jerry Feldman)]

On 06/18/2013 01:09 AM, Bill Bogstad wrote:
> p
>
> On Mon, Jun 17, 2013 at 5:03 PM, Greg Rundlett (freephile)
> <greg at freephile.com> wrote:
>> I'm wondering if anyone has success stories about finding dead code in
>> large (C) projects?
> I'm not sure I can provide any help with this question, but I think it
> would help if you defined
> what you mean by dead code.   Some possible definitions:
>
> 1. Functions which are defined but there is no static call site in the
> code base.
>
> 1a. Like 1, but with all possible definitions of various C
> preprocessor definitions.  Not just the ones for your current build
> environment.
>
> 2. What about conditional statements that will always be true/false
> statically OR for any real runtime enviroment. Is the alternative
> branch of the conditional dead code?
>
> 3. What about functions that are assigned to (arrays/structs of)
> function pointers?   You can't really tell until runtime if those
> functions will ever be called.   Kind of like #2...
>
> BTW, I took a quick look at
> http://www.samba.org/ftp/unpacked/junkcode/findstatic.pl and it
> appears to handle case #1, but not 1a.
>
> As Tom suggests, this is related to comprehensive unit tests; but
> determining if your unit tests
> are complete is not always easy and may be difficult to do.   For
> example, injecting errors
> into system calls in order to test error recovery can be difficult to
> accomplish.  Getting fork() to fail could be a challenge.
>
> In the end, I think your goal is related to the halting problem which
> is impossible in the general case.  So use the tools, you are
> comfortable with and accept that you probably won't find everything.
>
Quite a while ago we used Purify not only to check the code but also to 
look at code coverage. Every language has the same issues. Also, in the 
past I have been able to cause fork(2) to fail as well as malloc(3) and 
sbreak(2). While Purify is unique there are many other good tools.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90