Dead code detection in legacy C/C++ project [closed]

Asked 23/10, 2008 at 9:18 Answered 16/7, 2009 at 20:55

Solved c++automation static-analysis legacy-code dead-code

How would you go about dead code detection in C/C++ code? I have a pretty large code base to work with and at least 10-15% is dead code. Is there any Unix based tool to identify this areas? Some pieces of code still use a lot of preprocessor, can automated process handle that?

Uniocular answered 23/10, 2008 at 9:18 Comment(1)

Theres a similar question with more activity here: #4814447 – Breakthrough 10/2, 2011 at 20:5

You could use a code coverage analysis tool for this and look for unused spots in your code.

A popular tool for the gcc toolchain is gcov, together with the graphical frontend lcov (http://ltp.sourceforge.net/coverage/lcov.php).

If you use gcc, you can compile with gcov support, which is enabled by the '--coverage' flag. Next, run your application or run your test suite with this gcov enabled build.

Basically gcc will emit some extra files during compilation and the application will also emit some coverage data while running. You have to collect all of these (.gcdo and .gcda files). I'm not going in full detail here, but you probably need to set two environment variables to collect the coverage data in a sane way: GCOV_PREFIX and GCOV_PREFIX_STRIP...

After the run, you can put all the coverage data together and run it through the lcov toolsuite. Merging of all the coverage files from different test runs is also possible, albeit a bit involved.

Anyhow, you end up with a nice set of webpages showing some coverage information, pointing out the pieces of code that have no coverage and hence, were not used.

Off course, you need to double check if the portions of code are not used in any situation and a lot depends on how good your tests exercise the codebase. But at least, this will give an idea about possible dead-code candidates...

Carburet answered 23/10, 2008 at 9:38 Comment(2)

I'm still stuck with Sun C++ compilers but we have gcc migration underway so I'm gonna try this out. Thanks. – Uniocular 23/10, 2008 at 9:43

Code Coverage analysis (such as gcov) can provide data which code is not covered by the particular run(s) of the software -- code that is not covered is not necessarily dead code. A different run of the software (such as different compile option, different runtime option or different input data) or a different execution path (such as error handling) may trigger a function that was not invoked earlier. – Magree 15/1, 2018 at 17:58

Compile it under gcc with -Wunreachable-code.

I think that the more recent the version, the better results you'll get, but I may be wrong in my impression that it's something they've been actively working on. Note that this does flow analysis, but I don't believe it tells you about "code" which is already dead by the time it leaves the preprocessor, because that's never parsed by the compiler. It also won't detect e.g. exported functions which are never called, or special case handling code which just so happen to be impossible because nothing ever calls the function with that parameter - you need code coverage for that (and run the functional tests, not the unit tests. Unit tests are supposed to have 100% code coverage, and hence execute code paths which are 'dead' as far as the application is concerned). Still, with these limitations in mind it's an easy way to get started finding the most completely bollixed routines in the code base.

This CERT advisory lists some other tools for static dead code detection

Refugio answered 23/10, 2008 at 14:50 Comment(3)

This answer is no more valid do to the fact that -Wunreachable-code option was removed from gcc. gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html – Elocution 15/12, 2013 at 23:19

Shame. For many purposes "unstable" dead code detection is still better than nothing. Aside from anything else, perfect dead code detection in general is impossible (halting problem), so everyone knows that whatever tool they use is imperfect. Presumably someone actually cares that it's more imperfect with -O0 than it is with -O3, or doesn't want new warnings whenever the optimizer improves. – Refugio 15/12, 2013 at 23:42

Still, if your code uses no new features you could still use an old gcc as a static analysis tool. So my answer isn't completely wrong. Bit of a reach, I know ;-) – Refugio 15/12, 2013 at 23:48

For C code only and assuming that the source code of the whole project is available, launch an analysis with the Open Source tool Frama-C. Any statement of the program that displays red in the GUI is dead code.

If you have "dead code" problems, you may also be interested in removing "spare code", code that is executed but does not contribute to the end result. This requires you to provide an accurate modelization of I/O functions (you wouldn't want to remove a computation that appears to be "spare" but that is used as an argument to printf). Frama-C has an option for pointing out spare code.

Vizcacha answered 16/7, 2009 at 20:55 Comment(0)

Your approach depends on the availability (automated) tests. If you have a test suite that you trust to cover a sufficient amount of functionality, you can use a coverage analysis, as previous answers already suggested.

If you are not so fortunate, you might want to look into source code analysis tools like SciTools' Understand that can help you analyse your code using a lot of built in analysis reports. My experience with that tool dates from 2 years ago, so I can't give you much detail, but what I do remember is that they had an impressive support with very fast turnaround times of bug fixes and answers to questions.

I found a page on static source code analysis that lists many other tools as well.

If that doesn't help you sufficiently either, and you're specifically interested in finding out the preprocessor-related dead code, I would recommend you post some more details about the code. For example, if it is mostly related to various combinations of #ifdef settings you could write scripts to determine the (combinations of) settings and find out which combinations are never actually built, etc.

Poppas answered 23/10, 2008 at 14:30 Comment(0)

Both Mozilla and Open Office have home-grown solutions.

Mauer answered 23/10, 2008 at 18:32 Comment(2)

Both the links are inaccessible now. Can anybody update? – Lyda 17/4, 2017 at 2:15

I've switched the first link from a blog post to a (hopefully longer lasting) documentation page. The Open Office link appears to work. – Mauer 17/4, 2017 at 5:19

g++ 4.01 -Wunreachable-code warns about code that is unreachable within a function, but does not warn about unused functions.

int foo() { 
    return 21; // point a
}

int bar() {
  int a = 7;
  return a;
  a += 9;  // point b
  return a;
}

int main(int, char **) {
    return bar();
}

g++ 4.01 will issue a warning about point b, but say nothing about foo() (point a) even though it is unreachable in this file. This behavior is correct although disappointing, because a compiler cannot know that function foo() is not declared extern in some other compilation unit and invoked from there; only a linker can be sure.

Segregation answered 18/2, 2009 at 21:41 Comment(0)

Dead code analysis like this requires a global analysis of your entire project. You can't get this information by analyzing translation units individually (well, you can detect dead entities if they are entirely within a single translation unit, but I don't think that's what you are really looking for).

We've used our DMS Software Reengineering Toolkit to implement exactly this for Java code, by parsing all the compilation-units involved at once, building symbol tables for everything and chasing down all the references. A top level definition with no references and no claim of being an external API item is dead. This tool also automatically strips out the dead code, and at the end you can choose what you want: the report of dead entities, or the code stripped of those entities.

DMS also parses C++ in a variety of dialects (EDIT Feb 2014: including MS and GCC versions of C++14 [EDIT Nov 2017: now C++17]) and builds all the necessary symbol tables. Tracking down the dead references would be straightforward from that point. DMS could also be used to strip them out. See http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Monadnock answered 3/7, 2009 at 9:54 Comment(0)

Bullseye coverage tool would help. It is not free though.

Belen answered 23/10, 2008 at 9:23 Comment(2)

Is it worth money? Any experience with it? They have a trial so I might check it out, if it works, we can buy it :) – Uniocular 23/10, 2008 at 9:34

Yes.. I have used on Symbian Platform... Its definitely worth buying it – Belen 24/11, 2008 at 11:22

Recommended topics

Hot tags