레거시 C/C++ 프로젝트에서의 데드 코드 감지

Question

C/C++ 코드에서 불필요한 코드 탐지에 대해 어떻게 생각하십니까? 나는 꽤 큰 코드베이스를 가지고 있고 적어도 10-15 %는 죽은 코드이다. 이 영역을 식별 할 수있는 유닉스 기반 도구가 있습니까? 코드의 일부 조각은 여전히 ​​전처리기를 많이 사용하며 자동화 된 프로세스가이를 처리 할 수 ​​있습니까?

Answer 1

코드 커버리지 분석 도구를 사용하여 코드에서 사용되지 않는 부분을 찾을 수 있습니다.

gcc 툴체인을위한 인기있는 도구는 그래픽 프론트 엔드 lcov (http://ltp.sourceforge.net/coverage/lcov.php)와 함께 gcov입니다.

gcc를 사용하는 경우 '--coverage'플래그로 활성화 된 gcov 지원으로 컴파일 할 수 있습니다. 그런 다음, gcov가 활성화 된 빌드로 애플리케이션을 실행하거나 테스트 슈트를 실행하십시오.

기본적으로 gcc는 컴파일하는 동안 몇 가지 추가 파일을 내보내고 실행 중에 응용 프로그램은 일부 적용 데이터를 방출합니다. 이 모든 파일 (.gcdo 및 .gcda 파일)을 수집해야합니다. 여기서 자세히 다루지는 않겠지 만, GCOV_PREFIX 및 GCOV_PREFIX_STRIP ...

실행 후 모든 커버리지 데이터를 넣을 수 있습니다. 함께 lcov 도구를 통해 실행하십시오. 서로 다른 테스트 실행의 모든 ​​커버리지 파일을 병합하는 것도 가능합니다.

아무리해도 적용 범위가 없으므로 사용되지 않은 코드 조각을 지적하면서 일부 범위 정보를 보여주는 멋진 웹 페이지가 만들어집니다.

물론 코드의 일부가 사용되지 않고 코드베이스를 얼마나 잘 실행하는지에 따라 코드의 부분이 많이 사용되는지 여부를 다시 확인해야합니다. 하지만 최소한, 이것은 가능한 죽은 코드 후보에 대한 아이디어를 줄 것입니다 ...

Answer 2

Bullseye 적용 범위 도구가 도움이됩니다. 그것은 비록 자유롭지 않다.

Answer 3

접근 방식은 자동 테스트에 달려 있습니다. 충분한 기능을 충당 할 수 있다고 믿는 테스트 스위트를 갖고 있다면, 이미 제시된 이전 답변처럼 커버리지 분석을 사용할 수 있습니다.

당신이 그리 운명이 아니라면, SciTools '이해하기와 같은 소스 코드 분석 도구를 살펴보면 많은 분석 보고서를 사용하여 코드를 분석하는 데 도움이 될 수 있습니다. 이 도구에 대한 내 경험은 2 년 전 이었으므로 자세한 내용을 설명 할 수는 없지만 버그 수정 및 질문에 대한 답변이 매우 빠른 처리 시간으로 인상적인 지원을 얻었습니다.

static source code analysis 페이지에 많은 다른 도구가 나와 있습니다.

그래도 충분히 도움이되지 않으며 특히 전 처리기 관련 데드 코드를 찾는 데 관심이있는 경우 코드에 대한 자세한 정보를 게시 할 것을 권장합니다. 예를 들어 #ifdef 설정의 다양한 조합과 관련이있는 경우 (조합) 설정을 결정하고 실제로 조합이없는 조합을 찾을 수있는 스크립트를 작성할 수 있습니다.

Answer 4

gcc에서 -Wunreachable -암호.

나는 버전이 더 최근 버전 일수록 더 나은 결과를 얻을 수 있다고 생각하지만, 그들이 적극적으로 노력해 왔던 것이 틀렸다는 인상을 받았다.이것은 플로우 분석을하지만, 컴파일러에 의해 결코 파싱되지 않기 때문에, 전 처리기를 떠날 때 이미 죽은 "코드"에 관해 알려주지 않는다고 생각합니다. 예 : 익스포트 된 함수는 결코 호출되지 않습니다. 특별한 경우를 처리하는 코드는 그 매개 변수로 함수를 호출하지 않기 때문에 불가능할 것입니다. 코드 커버리지가 필요합니다 (단위 테스트가 아닌 기능 테스트를 실행하십시오.) 단위 테스트는 은이 100 % 코드 적용 범위를 가지며 따라서 응용 프로그램과 관련하여 '죽은'코드 경로를 실행한다고 가정합니다. 그럼에도 불구하고 이러한 제한 사항을 염두에두면 코드베이스에서 가장 완벽하게 bollixed 된 루틴을 쉽게 찾을 수 있습니다.

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

g ++ 4.01 점 B에 대한 경고를 발행하지만,이 파일에 연결할 수없는 경우에도 foo는() (점 A)에 대해 아무 말도하지 않습니다. 컴파일러는 그 함수 foo()가 다른 컴파일 유닛에서 extern으로 선언되지 않고 거기에서 호출된다는 것을 알지 못하기 때문에 실망 스럽지만이 동작은 정확합니다. 링커 만 확신 할 수 있습니다.

Answer 7

이와 같은 코드 분석에는 전체 프로젝트를 전체적으로 분석해야합니다. 번역 단위를 개별적으로 분석하여이 정보를 얻을 수 없습니다. (실제로 번역 단위가 단일 번역 단위에 포함되어 있으면 죽은 항목을 감지 할 수 있지만 실제로 찾고있는 것은 아닙니다.)

DMS 소프트웨어 리엔지니어링 툴킷을 사용하여 Java 코드에 대해이 기능을 구현했습니다. 한 번에 모든 컴파일 - 유닛을 구문 분석하고 모든 것에 대한 기호 테이블을 작성하고 모든 참조를 추적합니다. 참조가없고 외부 API 항목이 아니라는 주장이없는 최상위 수준의 정의는 죽었습니다. 이 도구는 또한 자동으로 데드 코드를 제거하고 결국에는 원하는 항목을 선택할 수 있습니다. 데드 엔티티 보고서 또는 해당 항목이 제거 된 코드입니다.

DMS는 다양한 방언 (EDIT Feb 2014 : including MS and GCC versions of C++14 [EDIT Nov 2017: now C++17])에서 C++을 구문 분석하고 필요한 모든 기호 테이블을 작성합니다. 죽은 레퍼런스를 추적하는 것은 그 시점부터 직설적입니다. DMS는 또한 그들을 제거하기 위해 사용될 수 있습니다.

Answer 8

전체 코드의 경우 전체 프로젝트의 소스 코드를 사용할 수 있다고 가정하면 오픈 소스 도구 Frama-C을 사용하여 분석을 시작하십시오. GUI에 빨간색으로 표시되는 프로그램의 모든 문장은 죽은 코드입니다.

"dead code"문제가있는 경우 "spare code"를 제거하고 실행 된 코드는 가 아니며 최종 결과에 기여할 수 있습니다. 이를 위해서는 에 I/O 함수의 정확한 모델링을 제공해야합니다. 을 사용하면 printf의 인수로 사용되는 이 아닌 "예비"인 계산을 제거하지 않아도됩니다. Frama-C에는 예비 코드를 지적하는 옵션이 있습니다.