<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="tooling" xml:lang="ko">
<info>
<link type="guide" xref="index#general-guidelines"/>
<credit type="author copyright">
<name>Philip Withnall</name>
<email its:translate="no">philip.withnall@collabora.co.uk</email>
<years>2015</years>
</credit>
<include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>
<desc>다양한 작업을 처리할 올바른 도구 활용</desc>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>조성호</mal:name>
<mal:email>shcho@gnome.org</mal:email>
<mal:years>2016, 2017.</mal:years>
</mal:credit>
</info>
<title>도구 활용</title>
<p>개발 도구는 텍스트 편집기 및 컴파일러 말고도 굉장히 많습니다. 도구를 올바르게 활용하면 디버깅, 메모리 할당 및 시스템 콜, 기타 복잡한 문제의 추적이 쉬워집니다. 대부분 일반적으로 활용하는 일부 도구를 아래에 설명했습니다만, 특수 목적으로 활용하는 도구가 있으며, 필요하다면 활용해야합니다.</p>
<p>대단히 중요한 원칙은 출시 시기가 닥치기 전까지 최대한 많은 디버깅 옵션을 비활성화 하기보단 개발할 때 항상 활성화하는 조치입니다. 가능한 모든 디버그 도구를 활용하여 꾸준히 코드를 테스트하면, 버그가 코드에 깊이 뿌리 박혀 없애기 어려워 지기 전 빨리 잡을 수 있습니다.</p>
<p>실제로, 모든 컴파일러 및 기타 도구의 경고를 활성화하고 경고 메시지가 나타났을 경우 빌드 과정의 오류로 간주하여 실패하도록 설정하라는 의미입니다.</p>
<synopsis>
<title>요약</title>
<list>
<item><p>2차 컴파일러로 자주 컴파일하십시오(<link xref="#gcc-and-clang"/>).</p></item>
<item><p>다양한 컴파일러 경고 범위를 활성화하고, 경고 항목을 치명적인 항목으로 간주하십시오(<link xref="#gcc-and-clang"/>).</p></item>
<item><p>GDB를 활용하여 코드를 디버깅하고 한 단계씩 실행하십시오(<link xref="#gdb"/>).</p></item>
<item><p>Valgrind를 활용하여 메모리 사용 상태, 메모리 오류, 캐시 및 CPU 성능, 스레드 오류를 분석하십시오(<link xref="#valgrind"/>).</p></item>
<item><p>gcov 및 lcov를 활용하여 단위 테스트 범위를 분석하십시오(<link xref="#gcov-and-lcov"/>).</p></item>
<item><p>컴파일러 정리기를 활용하여 메모리, 스레드 및 비지정 동작 문제를 분석하십시오(<link xref="#sanitizers"/>).</p></item>
<item><p>cronjob을 활용하여 Coverity에 제출하고 정적 분석 오류가 나타나는대로 수정하십시오(<link xref="#coverity"/>).</p></item>
<item><p>Clang 정적 분석기 및 Tartan을 주기적으로 활용하여 로컬에서 꾸준히 분석할 수 있는 오류를 하나하나 수정하십시오(<link xref="#clang-static-analyzer"/>).</p></item>
</list>
</synopsis>
<section id="gcc-and-clang">
<title>GCC와 Clang</title>
<p><link href="https://gcc.gnu.org/onlinedocs/gcc/">GCC</link>는 리눅스용 표준 C 컴파일러입니다. <link href="http://clang.llvm.org/docs/UsersManual.html">Clang</link>이라는 기능 호환 대안도 있습니다. 이 중 하나를 주 컴파일러(아마도 GCC)를 선택하겠지만, 코드에서 나타나는 오류 및 경고 출력이 약간 다르기 때문에, 경우에 따라 코드를 컴파일할 때 다른 컴파일러를 산택합니다. Clang에는 코드를 컴파일하거나 실행하지 않고도 코드의 오류를 찾아낼 수 있는 정적 분석 도구가 있습니다. <link xref="#clang-static-analyzer"/>를 참고하십시오.</p>
<p>두 컴파일러는 가능한 많은 경고 플래그를 설정하여 사용해야 합니다. 컴파일러 경고가 때로는 거짓 양성 결과를 출력할 수도 있지만, 대부분의 경고는 코드의 문제를 정확하게 짚어내며, 이 문제를 무시하기 보단 수정해아합니다. 모든 경고 플래그를 활성화하고 <code>-Werror</code> 플래그(모든 경고를 컴파일 실패로 간주)를 지정하는 개발 정책은 나타나는대로 최대한 경고를 수정하겠다는 의지를 고취하며, 코드 품질 개선에 도움을줍니다. 경고를 무시하면, 경고로 나타난 문제로 인해 발생한 버그를 디버깅 세션 내내 오랫동안 찾게 만듭니다. 개발 기간이 끝날 때까지 경고를 무시하면, 경고를 활성화하고 경고문을 따라 문제를 수정하는데 엄청난 시간을 소비합니다.</p>
<p>GCC와 Clang은 다양한 범위의 컴파일러 플래그를 지원하는데, 일부는 최근 범용 코드에먼 관련이 있습니다(예를 들면, 다른 코드는 오래되었거나 특정 아키텍처에서만 동작합니다). 타당한 활성화 플래그 셋을 결정하는건 까다로울 수 있어 <link href="http://www.gnu.org/software/autoconf-archive/ax_compiler_flags.html"> <code>AX_COMPILER_FLAGS</code></link> 매크로가 있습니다.</p>
<p><code>AX_COMPILER_FLAGS</code> 매크로는 언제나 가은 컴파일러 경고 설정을 활성화하며, 경고 설정을 활성화하기 전에 컴파일러의 지원 유무를 테스트합니다. 이 과정에서 GCC 및 Clang에서 지원하는 플래그 모음의 차이를 확인합니다. 이 매크로를 사용하려면 <file>configure.ac</file> 파일에 <code>AX_COMPILER_FLAGS</code> 플래그를 추가하십시오. autoconf-archive 매크로의 트리 내 사본을 활용한다면, 프로젝트의 <file>m4/</file> 디렉터리에 <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_compiler_flags.m4"> <file>ax_compiler_flags.m4</file></link> 파일을 복사하십시오. 참고로, 다음 autoconf-archive 매크로가 어떤 GPL 라이선스를 적용하는지에 따라 다르기 때문에 트리에 복사를 못할 수도 있습니다. 프로젝트에서 빌드할 때만 동작하도록 autoconf-archive에 그냥 두는게 낫습니다:</p>
<list>
<item><p><code>ax_append_compile_flags.m4</code></p></item>
<item><p><code>ax_append_flag.m4</code></p></item>
<item><p><code>ax_check_compile_flag.m4</code></p></item>
<item><p><code>ax_require_defined.m4</code></p></item>
</list>
<p><code>AX_COMPILER_FLAGS</code>에서는 출시판 빌드 목적으로 <code>-Werror</code> 플래그 비활성화를 지원하므로, 출시판은 항상 더 많은 경고 메시지를 내보낼 수 있는 새 컴파일러로 빌드할 수도 있습니다. 출시판 빌드(그리고 오직 출시 빌드 용도로만) 목적으로 이 기능을 활성화하려면 세번째 매개변수 값을 ‘yes’로 설정하십시오. 개발 및 CI 빌드 과정에서는 항상 <code>-Werror</code> 플래그를 활성화해야합니다.</p>
<p>출시판 빌드는 <code>AX_COMPILER_FLAGS</code>에 결과를 바로 전달할 수 있는 <link href="http://www.gnu.org/software/autoconf-archive/ax_is_release.html"><code>AX_IS_RELEASE</code></link>를 활용하여 찾을 수 있습니다:</p>
<code style="valid">AX_IS_RELEASE([git])
AX_COMPILER_FLAGS([WARN_CFLAGS],[WARN_LDFLAGS],[$ax_is_release])</code>
<p>출시 안정 정책의 선택(<code>AX_IS_RELEASE</code>의 첫번째 인자)은 프로젝트의 <link xref="versioning">버전 부여 안정성</link>을 취할 프로젝트 별로 설정해야 합니다.</p>
</section>
<section id="gdb">
<title>GDB</title>
<p>GDB는 리눅스에서 사용하는 C언어용 표준 디버거입니다. 프로그램의 갑작스러운 중단을 디버깅할 때 매우 보편적으로 사용하며, 프로그램의 코드를 실행할 때, 단계별로 살펴보려는 용도로도 활용합니다. GDB 사용 완벽 지침서는 <link href="https://sourceware.org/gdb/current/onlinedocs/gdb/">여기</link>에 있습니다.</p>
<p>소스 트리에서 프로그램 실행시 GDB를 실행하려면 <cmd>libtool exec gdb --args <var>./program-name</var> <var>--some --arguments --here</var></cmd> 명령을 사용하십시오</p>
<p>libtool은 몇가지 libtool 변수를 설정하는 쉘 스크립트로 소스 트리상에서 컴파일한 각각의 이진 파일에 둘러싸여있기 때문에 GDB가 필요합니다. 설치한 실행 파일을 디버깅할 때는 필요하지 않습니다.</p>
<p>GDB는 코드의 각 부분의 중단점에서 실행할 작은 핵심 디버깅 스크립트를 만들 때 근본적으로 합칠 수 있는 여러가지 고급 기능이 있습니다. 때로는 (<link href="https://tecnocode.co.uk/2010/07/12/reference-count-debugging-with-gdb/">참조 카운트 디버깅</link> 같은 경우) 쓸 만한 접근 수단일 수 있지만, 어떤 경우에는 <link href="https://developer.gnome.org/glib/stable/glib-Message-Logging.html#g-debug"> <code>g_debug()</code></link> 함수로 디버깅 메시지를 출력하는게 더 간단한 방법일 수도 있습니다.</p>
</section>
<section id="valgrind">
<title>Valgrind</title>
<p>Valgrind는 프로그램의 동작을 측정하고 프로파일링하는 도구의 모음입니다. 제일 인기있는 도구는 <link xref="#memcheck">memcheck</link>지만, 몇가지 강력하고 쓸 만한 다른 도구도 있습니다. 다음 부분에서 개별적으로 다루겠습니다.</p>
<p>Valgrind를 활용하는 쓸 만한 방법은 Valgrind에서 확인한 수많은 오류를 나타내는 상태 코드를 반환하도록 설정한 Valgrind에서 프로그램의 단위 테스트 모음을 실행하는 방법입니다. <cmd>make check</cmd>의 일부로 실행할 때, Valgrind에서 문제를 찾지 못했다면 성공했다고 표시하고 그렇지 않으면 실패했다고 표시합니다. 그러나, 명령행의 Valgrind에서 <cmd>make check</cmd> 명령을 실행하면 항상 그렇지는 않습니다. <cmd>make check-valgrind</cmd> 타겟을 추가하여 명령행에서 자동으로 Valgrind를 실행하도록 <link href="http://www.gnu.org/software/autoconf-archive/ax_valgrind_check.html"> <code>AX_VALGRIND_CHECK</code></link> 매크로를 활용할 수 있습니다. 언급한 대로 활용하려면:</p>
<steps>
<item><p><link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> 파일을 프로젝트의 <file>m4/</file> 디렉터리에 복사하십시오.</p></item>
<item><p><file>configure.ac</file>에 <code>AX_VALGRIND_CHECK</code>를 추가하십시오.</p></item>
<item><p>단위 테스트를 넣은 각 디렉터리의 <file>Makefile.am</file> 파일에 <code>@VALGRIND_CHECK_RULES@</code> 코드를 추가하십시오.</p></item>
</steps>
<p><cmd>make check-valgrind</cmd> 명령을 실행하면, 도구마다 하나씩 만드는 <file>test-suite-*.log</file> 로그 파일에 결과를 저장합니다. 단위 테스트가 있는 디렉터리마다 이 명령을 실행해야 함을 참고하십시오.</p>
<p>Valgrind에는 <link href="http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress">파일 숨김 기법(suppression files)</link>으로 거짓 양성 결과를 없애는 방법이 있습니다. 이 목록으로 오류 추적 스택과 비교할 패턴을 나타냅니다. 오류로부터 나온 추적 스택이 숨김 항목의 일부와 일치하면, 보고하지 않습니다. 여러가지 이유로 GLib에서는 <link xref="#memcheck">memcheck</link>와 Valgrind 사용시 기본적으로 숨기는게 좋은 <link xref="#helgrind-and-drd">helgrind 및 drd</link>에서 수많은 거짓 양성 결과를 출력합니다. 이 때문에, 프로젝트에서 지정한대로 표준 GLib 숨김 파일 목록을 사용해야합니다.</p>
<p><code>AX_VALGRIND_CHECK</code> 매크로에서 파일을 숨기는 기능도 지원합니다:</p>
<code>@VALGRIND_CHECK_RULES@
VALGRIND_SUPPRESSIONS_FILES = my-project.supp glib.supp
EXTRA_DIST = $(VALGRIND_SUPPRESSIONS_FILES)</code>
<section id="memcheck">
<title>memcheck</title>
<p>memcheck는 메모리 사용 및 할당 분석기입니다. 메모리 접근 및 힙 수정 문제(할당 및 해제)를 찾아냅니다. 상당히 견고하고 잘 다듬어진 도구이며, 출력 결과는 전적으로 신뢰할 수 있습니다. ‘분명하게’ 메모리 누수가 있다고 한다면, 고쳐야 할 메모리 누수가 분명하게 있으며, ‘잠재적’ 메모리 누수가 있다면, 메모리 누수를 수정해야 하거나, 초기화 과정에서 메모리를 할당한 후 힙 메모리 공간을 해제하지 않고 프로그램 동작 내내 사용할 지도 모릅니다.</p>
<p>설치한 프로그램에 대해 memcheck를 실행하려면 다음 명령을 활용하십시오:</p>
<p><cmd>valgrind --tool=memcheck --leak-check=full <var>my-program-name</var></cmd></p>
<p>또는 원본 디렉터리에서 프로그램을 실행한다면, 다음 명령을 사용하여 libtool 보조 스크립트에서 메모리 누수 검사 실행을 막으십시오:</p>
<p><cmd>libtool exec valgrind --tool=memcheck --leak-check=full <var>./my-program-name</var></cmd></p>
<p>(디버깅 심볼을 둔채로 컴파일 한 경우)Valgrind는 메모리 오류를 정확히 찾아 수정할 수 있도록 짧은 역추적 기록에서 자체적으로 찾아낸 메모리 문제를 나타냅니다.</p>
<p>memcheck 사용 완벽 지침서는 <link href="http://valgrind.org/docs/manual/mc-manual.html">여기</link>에 있습니다.</p>
</section>
<section id="cachegrind-and-kcachegrind">
<title>cachegrind 및 KCacheGrind</title>
<p>cachegrind는 인스트럭션 실행도 측정할 수 있는 캐시 성능 프로파일러기 때문에 프로그램의 일반 성능 프로파일링에 매우 쓸 만합니다. <link href="http://kcachegrind.sourceforge.net/html/Home.html">KCacheGrind</link>는 프로파일링 데이터를 시각화하고 탐색할 수 있게 하는 쓸 만한 도구이며, 언급한 두가지 도구를 따로 사용하는 경우는 드뭅니다.</p>
<p>cachegrind는 프로세서 메모리 계층을 시뮬레이팅하기에 <link href="http://valgrind.org/docs/manual/cg-manual.html#cg-manual.annopts.accuracy">완전히 정확하지 않은</link> 상황이 있을 수도 있습니다. 그러나, 이 프로그램의 결과는 항상 주요 지점의 성능 디버깅에 충분히 대표적으로 쓸 만합니다.</p>
<p>cachegrind 사용 완벽 지침서는 <link href="http://valgrind.org/docs/manual/cg-manual.html">여기</link>에 있습니다.</p>
</section>
<section id="helgrind-and-drd">
<title>helgrind 및 drd</title>
<p>helgrind와 drd는 메모리 접근시 레이스 컨디션과 <link href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html"> POSIX pthreads API</link>의 남용을 검사하는 스레드 오류 감지기입니다. 비슷한 도구지만 다른 기법으로 구현했기에 두가지 도구를 모두 사용해야합니다.</p>
<p>helgrind와 drd에서 찾는 오류는 일관성있는 잠금 조치 없이 다중 스레드의 데이터 접근, 잠금 승인 순서의 바뀜, 뮤텍스를 잠그는 동안 해제 동작, 잠긴 뮤텍스의 잠금, 잠금 해제한 뮤텍스의 잠금 해제, 및 몇가지 오류입니다. 각 오류를 발견하면, 몇가지 보고서로 콘솔에 출력하며, 이 보고서에는 관련된 뮤텍스 및 스레드의 할당 또는 생성 세부 정보가 들어있어, 관련 스레드와 뮤텍스의 자세한 내용을 찾을 수 있습니다.</p>
<p>helgrind와 drd는 memcheck또는 cachegrind보다 거짓양성 결과를 더 많이 출력할 수 있어, 좀 더 신중하게 출력 결과를 살펴봐야 합니다. 그러나, 스레드 처리 문제는 경험이 있는 프로그래머에게 마저도 악명이 자자할 정도로 찾기 어렵기에 helgrind와 drd 오류를 가볍게 무시해선 안됩니다.</p>
<p>helgrind와 drd 사용 완벽 지침서는 <link href="http://valgrind.org/docs/manual/hg-manual.html">이 곳</link>과 <link href="http://valgrind.org/docs/manual/drd-manual.html">이 곳</link>에 있습니다.</p>
</section>
<section id="sgcheck">
<title>sgcheck</title>
<p>sgcheck는 배열의 길이를 넘겨 짚는 접근을 찾아내는 배열 범위 검사기입니다. 나온 지 얼마 되지 않은 도구이며, 여전히 시험판으로 간주하므로 다른 도구에 비해 (잘못된) 거짓 양성 결과가 나올 수 있습니다.</p>
<p>시험판이므로 Valgrind에 <cmd>--tool=sgcheck</cmd>가 아닌, <cmd>--tool=exp-sgcheck</cmd> 매개 변수를 전달하여 실행해야합니다.</p>
<p>완전한 sgcheck 사용 지침은 <link href="http://valgrind.org/docs/manual/sg-manual.html">여기에 있습니다</link>.</p>
</section>
</section>
<section id="gcov-and-lcov">
<title>gcov 및 lcov</title>
<p><link href="https://gcc.gnu.org/onlinedocs/gcc/Gcov.html">gcov</link>는 GCC로 빌드한 프로파일링 도구이며, 컴파일 시간의 추가 코드를 넣어 코드를 분석합니다. 이 프로그램을 실행할 때, 코드에서 <file>.gcda</file> 와 <file>.gcno</file> 프로파일링 출력 파일이 나옵니다. 이 파일은 코드 실행 영역의 실행 시간 시각 보고서, 다른 곳에서보단 프로젝트에서 더 많이 실행하는 코드의 줄을 강조하는 <cmd>lcov</cmd> 도구로 분석할 수 있습니다.</p>
<p>코드 범위 데이터 수집의 결정적인 사용은 단위 테스트를 수행할 때입니다. 단위 테스트로 상당히 많은 범위의 코드(어떤 줄을 실행했는지?)를 안다면 단위 테스트 범위 확장을 이끄는데 사용할 수 있습니다. 보통 단위 테스트로 얻어낸 코드 범위를 검사하고, 검사 범위가 100%에 가깝게 도달하면 전체 프로젝트를 테스트했다고 봐도 됩니다. 종종, 단위 테스트는 대분의 코드를 시험해보지만, 일부 제어문을 테스트하지 않으므로 일부 버그가 남아있을 수 있습니다.</p>
<p>lcov는 <link href="http://en.wikipedia.org/wiki/Code_coverage#Basic_coverage_criteria">분기분 범위 측정</link>을 지원하여, 안정성이 중요한 코드 범위 시험에는 적절치 않습니다. 불안정 중대 코드에 안성맞춤입니다.</p>
<p>컴파일 시간 및 실행 시간에 코드 범위를 활성화하면, 제공한 메크로로 단순하게 처리할 수 있습니다. <link href="http://www.gnu.org/software/autoconf-archive/ax_code_coverage.html"> <code>AX_CODE_COVERAGE</code></link> 매크로는 빌드 시스템에 <cmd>make check-code-coverage</cmd> 타겟을 추가하여 코드 범위 활성화 후 단위 테스트를 진행하며 <cmd>lcov</cmd> 명령으로 보고서를 만듭니다.</p>
<p>프로젝트에 <code>AX_CODE_COVERAGE</code> 지원을 추가하려면:</p>
<steps>
<item><p><link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> 파일을 프로젝트의 <file>m4/</file> 디렉터리에 복사하십시오.</p></item>
<item><p><file>configure.ac</file> 파일에 <code>AX_CODE_COVERAGE</code>를 추가하십시오.</p></item>
<item><p>최상위 <file>Makefile.am</file> 파일에 <code>@CODE_COVERAGE_RULES</code>를 추가하십시오.</p></item>
<item><p>예를 들어 모든 라이브러리를 대상으로 하지만 코드 단위 테스트를 수행하지 않는다면, 원하는 각 범위를 대상으로 automake의 <code><var>*</var>_CFLAGS</code> 변수에 <code>$(CODE_COVERAGE_CFLAGS)</code>를 추가하십시오. <code>$(CODE_COVERAGE_LDFLAGS)</code> 와 <code><var>*</var>_LDFLAGS</code>도 똑같이 처리하십시오.</p></item>
</steps>
<p>gcov 및 lcov 문서는 <link href="http://ltp.sourceforge.net/coverage/lcov.php">여기에 있습니다</link>.</p>
</section>
<section id="sanitizers">
<title>주소, 스레드 및 비정의 동작 정리 프로그램</title>
<p>GCC와 Clang에서는 여러가지 정리기가 있습니다. 실행 시간에 추가 코드를 설정하여 프로그램에 추가로 컴파일할 부분을 검사하며, 여러가지 잘못된 동작의 플래그를 설정합니다. 강력하지만, 프로그램을 다시 컴파일할 때 이런 기능을 활성화/비활성화하려면 특히 활성화해야합니다. 여러가지를 동시에 활성화하거나 <link xref="#valgrind">Valgrind</link>와 같은 도구를 동시에 활용할 수 없습니다. 아직 나온 지 얼마 안됐기 때문에 다른 도구와의 집약도가 낮습니다.</p>
<p>GCC와 Clang에서는 동일한 여러 컴파일러 옵션을 수용하는 모든 정리 프로그램이 있습니다.</p>
<section id="address-sanitizer">
<title>주소 정리기</title>
<p><link href="https://code.google.com/p/address-sanitizer/">address sanitizer</link>(‘asan’)은 C와 C++ 프로그램에서 메모리 할당 해제 후 사용 및 버퍼 오버플로우 버그를 찾습니다. 완전한 asan 사용 지침서는 <link href="http://clang.llvm.org/docs/AddressSanitizer.html#usage">Clang용으로 있습니다</link>만, GCC 용은 아직 작업중입니다.</p>
</section>
<section id="thread-sanitizer">
<title>스레드 정리기</title>
<p><link href="https://code.google.com/p/thread-sanitizer/">thread sanitizer</link>(‘tsan’)은 메모리 할당시 급하게 데이터를 넣는 코드와, POSIX 스레드 처리 API의 광범위한 오용 사례를 찾습니다. 완전한 tsan 사용 지침서는 <link href="http://clang.llvm.org/docs/ThreadSanitizer.html#usage">Clang용으로 있습니다</link>만, GCC 용은 아직 작업중입니다.</p>
</section>
<section id="undefined-behavior-sanitizer">
<title>비정의 동작 정리기</title>
<p>undefined behavior sanitizer (‘ubsan’)은 C 프로그램에서 잠재적으로 정의하지 않은 여러가지 동작을 찾아내는 작은 진단 프로그램 모음입니다. ubsan 활성화 방법 모음은 <link href="http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation">Clang용으로 있습니다</link>만, GCC 용은 아직 작업중입니다.</p>
</section>
</section>
<section id="coverity">
<title>Coverity</title>
<p><link href="http://scan.coverity.com/">Coverity</link>는 현존하는 상업용 정적 분석 도구 중 가장 유명하고 규모가 큰 도구 중 하나입니다. 그러나 오픈 소스 프로젝트에서 무료로 쓸 수 있으며, 어떤 프로젝트의 경우 <link href="https://scan.coverity.com/users/sign_up">가입</link>하는게 좋습니다. 자체적으로 일부 분석 도구를 실행하여 <link href="https://scan.coverity.com/faq#how-get-project-included-in-scan">분석을 진행</link>하며, Coverity 사이트에 소스 코드를 업로드한 후 타르볼 결과를 가져옵니다. 프로젝트 참여 구성원은 결과를 프로젝트 소스코드의 주석 형식(lcov에서 결과를 보여주는 방식과 비슷)으로 온라인으로 볼 수 있습니다.</p>
<p>Coverity는 로컬에서만 실행할 수는 없으며 빌드 시스템에 제대로 붙일 수 없습니다. 허나, 정기적으로 프로젝트를 자동으로 검사하고 타르볼로 압축하여 Coverity로 업로드하는 스크립트는 있습니다. 추천 방식은 프로젝트 git 저장소를 온전히 체크아웃하는 스크립트를 서버에서 주기적(보통 cronjob 방식)으로 실행하는 방식입니다. Coverity는 새 정적 분석 문제를 프로젝트 구성원에게 전자메일로 알려주어 <link xref="#gcc-and-clang">컴파일러 경고</link> 정보를 얻을 수 있습니다: 모든 정적 분석 경고를 하나하나 없앤 후, 새로 나타나는 경고를 하나하나 처리해나가십시오.</p>
<p>Coverity는 우수하지만 완벽하진 않으며 거짓 양성 결과가 많이 나옵니다. 이 결과는 온라인 인터페이스에서 무시해야합니다.</p>
</section>
<section id="clang-static-analyzer">
<title>Clang 정적 분석기</title>
<p>자체적으로 정적 분석을 수행할 때 사용할 수 있는 도구는 <link xref="#gcc-and-clang">Clang 컴파일러</link>와 개발한 <link href="http://clang-analyzer.llvm.org/">Clang 정적 분석기</link>입니다. 컴파일러가 찾을 수 없어 실행 시간에만 (단위 테스트로) 찾아낼 수 있는 C 코드의 다양한 문제를 찾아냅니다.</p>
<p>Clang은 일부 거짓 양성 결과를 내며, 이 결과를 무시할 간편한 방법이 없습니다. 거짓 양성 출력을 수정할 수 있게 <link href="http://clang-analyzer.llvm.org/faq.html#suppress_issue">정적 분석기 버그를 보고</link>하는 방안을 추천합니다.</p>
<p>Clang 사용법 완벽 안내서는 <link href="http://clang-analyzer.llvm.org/scan-build.html">여기</link>에 있습니다.</p>
<section id="tartan">
<title>Tartan</title>
<p>그러나, Clang 정적 분석기의 모든 역량을 위해서라면, GLib 같은 일부 라이브러리의 문제를 찾을 수 없습니다. 프로젝트가 GLib만을 사용하거나 (Clang이 이해하는) POSIX API를 적게 활용한다면 문제가 됩니다. Clang 정적 분석기에 맞춰서 일반 GLib API 일부 사용 검사를 지원하도록 Clang 기능을 확장하는데 쓸 수 있는 <link href="http://people.collabora.com/~pwith/tartan/">Tartan</link> 플러그인이 있습니다.</p>
<p>Tartan은 나타난 지 얼마 안된 프로그램이며, 거짓 양성 결과를 내기도 하고, 일부 코드에서 실행할 때 갑작스럽게 끝나는 경우가 있습니다. 그러나 적절한 버그를 좀 빨리 찾을 수 있으며, 코드에서 GLib를 사용할 때 새 오류를 찾아내려는 목적으로 코드 기반을 자주 실행할 때 쓸 만합니다. <link href="http://people.collabora.com/~pwith/tartan/#troubleshooting">Tartan 사용 중 나타나는 문제를 알려주십시오</link>.</p>
<p>Clang 정적 분석기와 Tartan을 사용하는 완벽 지침서는 <link href="http://people.collabora.com/~pwith/tartan/#usage-standalone">여기에 있습니다</link>. 올바르게 설치했다면, 일밭 정적 분석기 출력과 Tartan 출력이 섞여서 나옵니다.</p>
</section>
</section>
</page>