Обнаружение мертвого кода в устаревшем проекте C/C++

Question

Как вы могли бы обнаружить обнаружение мертвого кода в коде C/C++? У меня есть довольно большая база кода для работы и по крайней мере 10-15% - это мертвый код. Есть ли какой-либо инструмент на основе Unix для определения этих областей? Некоторые фрагменты кода все еще используют много препроцессоров, может ли автоматизировать обработку этого процесса?

Answer 1

Для этого вы можете использовать инструмент анализа покрытия кода и искать неиспользуемые точки в коде.

Популярным инструментом для gcc toolchain является gcov вместе с графическим интерфейсом lcov (http://ltp.sourceforge.net/coverage/lcov.php).

Если вы используете gcc, вы можете скомпилировать его с поддержкой gcov, который активируется флагом '--coverage'. Затем запустите приложение или запустите тестовый пакет с помощью этой сборки с поддержкой gcov.

В основном gcc выдаст некоторые дополнительные файлы во время компиляции, и приложение также выдаст некоторые данные покрытия во время работы. Вы должны собрать все эти файлы (.gcdo и .gcda). Я не буду здесь подробно, но вам, вероятно, нужно установить две переменные среды для сбора данных о покрытии разумным способом: GCOV_PREFIX и GCOV_PREFIX_STRIP ...

После запуска вы можете поместить все данные покрытия и запустить его через lcov toolsuite. Также возможно объединение всех файлов покрытия из разных тестовых прогонов, хотя и немного задействованных.

Во всяком случае, вы получаете хороший набор веб-страниц, отображающих информацию о покрытии, указывая на фрагменты кода, которые не имеют покрытия и, следовательно, не использовались.

Конечно, вам нужно дважды проверить, не используются ли какие-либо части кода в любой ситуации, и многое зависит от того, насколько хороши ваши тесты на базе кода. Но, по крайней мере, это даст представление о возможных кандидатах на мертвый код ...

Answer 2

Bullseye инструмент покрытия поможет. Это не бесплатно.

Answer 3

Ваш подход зависит от наличия (автоматизированных) тестов. Если у вас есть набор тестов, которому вы доверяете, чтобы покрыть достаточное количество функциональных возможностей, вы можете использовать анализ покрытия, как уже говорили предыдущие ответы.

Если вам не повезло, вы можете изучить инструменты анализа исходного кода, такие как SciTools «Поймите, что вы можете проанализировать свой код, используя множество встроенных отчетов об анализе. Мой опыт работы с этим инструментом датируется 2 года назад, поэтому я не могу дать вам много подробностей, но помню, что у меня была впечатляющая поддержка с очень быстрыми моментами исправления ошибок и ответами на вопросы.

Я нашел страницу на static source code analysis, в которой перечислены многие другие инструменты.

Если это вам тоже не поможет, и вам особенно интересно узнать о мертвом коде, связанном с препроцессором, я бы порекомендовал вам опубликовать дополнительную информацию о коде. Например, если в основном это связано с различными комбинациями параметров #ifdef, вы можете писать сценарии для определения (комбинаций) настроек и выяснить, какие комбинации никогда не были построены и т. Д.

Answer 4

Скомпилировать его под gcc с помощью функции -Уничтожимый -код.

Я думаю, что чем более поздняя версия, тем лучше результаты, которые вы получите, но я могу ошибаться в своем впечатлении, что это то, над чем они активно работали.Обратите внимание, что это анализ потока, но я не думаю, что он говорит вам о «коде», который уже мертв к тому времени, когда он покидает препроцессор, потому что это никогда не анализируется компилятором. Он также не обнаруживает, например. экспортируемые функции, которые никогда не вызываются, или специальный код обработки случая, который так просто случается, потому что ничего не вызывает функцию с этим параметром - для этого вам требуется покрытие кода (и запускайте функциональные тесты, а не модульные тесты. предположил, что имеет покрытие 100% кода и, следовательно, выполняет коды кода, которые «мертвы» в отношении приложения). Тем не менее, с учетом этих ограничений, это простой способ начать поиск наиболее полных подпрограмм в базе кода.

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

Answer 5

Оба Mozilla и Open Office имеют доморощенные решения.

Answer 6

g ++ 4.01 -Wunreachable-code предупреждает о коде, недоступном внутри функции, но не предупреждает о неиспользуемых функциях.

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(); 
} 

г ++ 4,01 будет выдавать предупреждение о точке Ь, но ничего не говорят о Foo() (точка а), даже если он недоступен в этом файле. Такое поведение является правильным, хотя и неутешительным, поскольку компилятор не может знать, что функция foo() не объявлена ​​extern в какой-либо другой компиляционной единице и вызвана оттуда; только линкер может быть уверен.

Answer 7

Для анализа такого кода необходим глобальный анализ всего проекта. Вы не можете получить эту информацию, анализируя единицы перевода отдельно (ну, вы можете обнаружить мертвые объекты, если они полностью находятся в пределах одной единицы перевода, но я не думаю, что это то, что вы действительно ищете).

Мы использовали наш инструментарий для реинжиниринга программного обеспечения DMS для реализации именно этого для Java-кода, путем разбора всех задействованных единиц компиляции, создания таблиц символов для всех и преследования всех ссылок. Определение верхнего уровня без ссылок и никаких претензий на внешний элемент API не работает. Этот инструмент также автоматически удаляет мертвый код, и в конце вы можете выбрать то, что хотите: отчет мертвых объектов или код, лишенный этих объектов.

DMS также анализирует C++ на разных диалектах (EDIT Feb 2014: including MS and GCC versions of C++14 [EDIT Nov 2017: now C++17]) и создает все необходимые таблицы символов. Отслеживание мертвых ссылок было бы прямолинейным с этой точки. DMS также может использоваться для их снятия. См. http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Answer 8

Для кода C и при условии, что имеется исходный код всего проекта , запустите анализ с помощью инструмента с открытым исходным кодом Frama-C. Любой оператор программы, отображающий красный цвет в графическом интерфейсе, является мертвым кодом.

Если у вас есть проблемы с «мертвым кодом», вы можете быть заинтересованы в удалении «запасного кода», код которого выполняется, но не Внести свой вклад в решение проблемы. Это требует, чтобы вы предоставили точную моделирование функций ввода-вывода (вы бы не хотели, чтобы удалял вычисление, которое кажется «запасным», но , которое используется в качестве аргумента для printf). Frama-C имеет возможность указывать запасной код.