Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 837
Nazgob Avatar asked Oct 23 '08 09:10

Nazgob


People also ask

How do I get the dead code in C++?

One approach is to use "Find All References" context menu item on class and function names. If a class/function is only referenced in itself, it is almost certainly dead code. Another approach, based on the same idea, is to remove(comment out) files/functions from project and see what error messages you will get.

What causes dead code?

Dead code is the part of your application that can never be executed. Common causes include: Programming errors in conditional branches. Code that will never be reached because the input data will never cause a specific branch to be executed.

What is logically dead code?

Logically dead code are branches of software that cannot be reached given the logical conditions. Finding logically dead code is important because it can indicate the software was not written as originally intended. So simply, a code change made the branch no longer necessary.


2 Answers

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

like image 117
Johan Avatar answered Sep 19 '22 06:09

Johan


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

like image 45
Steve Jessop Avatar answered Sep 23 '22 06:09

Steve Jessop