Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] finding dead code in C projects

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> 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
> 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>
Boston Linux and Unix
PGP key id:3BC1EB90
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /