Improving Your Software with Xcode and Static Code Analysis Techniques

OSXDEV

Xcode 와 정적코드분석 테크닉으로 소프트웨어 성능향상

정적분석이란 위험한 프로그래밍 습관, 잘못된 언어 특성 사용, 소스코드의 잠재된 오류를 실제 실행시키지 않고 잡아내는 방법이다. Xcode로 C와 Objective-C 언어를 사용한다면, 정적분석 테크닉을 배워서 실제 개발과정에 적용한다면, 정말 훌륭한 품질향상을 꾀할수 있다. 개발과정중에 (컴파일 도중) 잠재적 오류를 "선행적"으로 잡아내는 것이, 나중에, "후발적"으로 잡아내는 것보다, 훨씬더 비용적으로 효율이 높은 것이다. 결과는 더 명확한 코드 그리고 더 안정적이고 유지보수 수월한 프로젝트이다.

정적 분석에는 몇가지 방법이 있는데, 정규 코드 분석, 소프트웨어 메트릭스, 수학적 분석(정규법)등이 대표적이다. 간편하고 강력한 검증 기법은 GNU Compiler Collection(GCC) C 컴파일러의 언어 및 경고 옵션을 사용해서 컴파일 과정에서 나타날 수 있는 많은 의미적 오류를 잡아내는 것이다. 이런 정적분석을 Xcode는 빌드 설정에서 그래픽 사용자 환경을 제공하여 더 쉽게 쓸 수 있게 해 준다.

이 글에서는, GCC를 이용해서 C, Objective_C언어를 검증하는 방법을 알아볼 것이다. GCC의 정적분석기능과 Xcode에서 이 기능을 사용하는 방법을 알아볼 것이다.(Xcode 2.3과 GCC 4.0.1을 사용할 것이다)

목차 1 정적분석의 소개 2 역사에 대해 3 GCC와 Xcode를 이용한 정적분석 3.1 Xcode에서 언어변종옵션과 경고 식별 세팅하기 3.2 언어 변종 세팅 사용하기 3.3 경고수준 설정 사용 4 경고의 단계 4.1 1단계 : 언어계열 옵션 4.2 2단계 : 언어계열옵션에 더해 호환 검증 4.3 3단계, 4단계 : 일반적거나 조금 들 일반적인 프로그램 오류보고 4.4 5단계 : 더 엄밀한 검사를 하는 옵션들 5 다른 옵션들 6 Objective-C 옵션들 7 프로젝트에서 정적분석 사용하기 8 결론 9 더 많은 정보

[편집] 정적분석의 소개

GCC는 컴파일 과정에서 2가지 형태의 확인을 한다. 하나는 문법, 또하나는 의미이다. "문법 확인"이란 지정한 프로그래밍 언어에서 받아 들여질 수 있는 문장인지에 관한 규칙을 참고한다. 그에 반해, "의미 확인"은 언어내에서 각 문장간의 의미와 관계를 참고한다. 리스트1을 보면 C언어의 문법과 의미오류의 예를 보여준다.

리스트1 C언어의 문법과 의미오류

int main(void) {
  int a = 14;
  int b = 99 // The missing ; generates a syntax error.
  printf("%f\n", a + b); // The type mismatch is a semantic error.
  return 0;
}

Xcode에서 GCC를 이용해 빌드를 할 경우, 가장 단순한 의미분석만을 한다. 더 엄밀한 의미분석을 위해서는 GCC에 옵션을 설정해 주어야 한다.

정적분석과정을 개발과정에 포함시키는 것은 마치 코드에 또다른 감시자를 참여시키는 것 혹은 코딩과정아래에 그물망을 치는 것과 같은 것이다. 정적분석은 위험한 프로그래밍 습관, 잘못된 언어의 특성 사용, 실수로 빠트리거나 한 잠재적 오류, 그리고 가장 원치않은 그 시점에 드러날 것 같은 숨겨진 문제점 등을 파악해 내는 역할을 한다.

[편집] 역사에 대해

유닉스 기반의 C 컴파일러 설계자는 컴파일러에서 광범위한 의미확인을 하려고 했었다. (Expert C Programming 의 저자) 피터 반 린덴이 지적하듯이, 컴파일러의 속도 향상과 컴파일러의 단순화를 위해서 의미확인 기능을 완전히 제거해 버렸다고 한다. (아래 "더 자세한 정보" 참조) 컴파일러에서 정적분석 기능을 제거한 다음, lint라는 다른 프로그램에 그 기능을 심었다. 하지만 문제는 프로그래머드이 lint를 별로 사용하지 않고, 컴파일러만 사용한다는 것이었다.

이러한 문제점을 인식하고 컴퍼일러 개발자들이 정적분석기능을 컴파일러에 다시 심기 시작했다. 최신 GCC에서는 상당한 수준의 정적분석 기능을 제공한다. 완전한 정적분석기능을 사용하기 위해서는 GCC와 함께 Splint같은 lint도구를 함께 사용해야 한다. (Splint는 애플의 Xcode도구가 아니다. Splint는 기존의 lint나 GCC보다 더 나은 정적분석을 제공하는 서드파티 도구다. splint.org에서 구할 수 있다.)

다음 예제를 보면 정적분석이 어떤 역할을 하는지 감이 올 것이다. 리스트2에 있는 코드는 표준 C 프로그램 혹은 일반적인 코코아 응용프로그램(Objective-C) 빌드세팅에서는 컴파일러가 별다른 경고를 발생시키지 않을 것이다.

리스트2: 경고메시지를 발생시키지 않는 코드

#include 
int addTen(int n);

int main(void) { 
  float x = addTen(11.95f);
  printf("%f\n", x);
  return 0;
}
int addTen(int n) {
  return n + 10;
}

위에서 보는 바와 같이 기본 세팅으로 컴파일을 하면 보안에 구멍이 생길 수도 있다.

정적 분석과정을 개발과정에 포함시키는 첫 과정으로 GCC가 제공하는 정적분석옵션에 무엇이 있는지 그리고 일반적인 개발 시나리오에 어떻게 적용하는지 알아봐야 겠다. Objective-C는 C의 상위개념이기 때문에, C 프로그램 옵션부터 살펴보는 것이 순서겠다. 이것들을 이해하고 나면, Objective-C 예제로 넘어가도록 한다.

[편집] GCC와 Xcode를 이용한 정적분석

GCC컴파일러는 두가지 형태의 정적분석 옵션을 제공한다. "언어변종 옵션"과 "경고 옵션"이다. 언어계열옵션은 정확히 말하면 문법적 혹은 의미적 분석은 아니다. 단지, 특정 언어의 변종형을 준수하는지 확인하는 역할을 한다.(Mac OS X Objective-C 프로그램은 코코아 프로그램이기 때문에, 여기서는 Objective-C 변종에 대해서는 다루지 않는다. 더 자세한 설명은, GCC 지침서의 3.6절 Objective-C 와 Objective-C++ 변종을 설정하는 옵션 편을 참조하기 바란다.

경고 옵션을 사용하면, 예측못했던 프로그램 오류로 이어질 수 있는 잠재적 문제점들을 컴파일러가 찾아내 준다. 언어 변종 옵션과 경고 옵션을 함께 사용해서 특정 언어 형태에 맞추어서 프로그램을 작성하고 잠재적 문제가 없다는 확신을 가지게 해준다.

[편집] Xcode에서 언어변종옵션과 경고 식별 세팅하기

GCC빌드 시스템에 특정 컴파일러 옵션을 주기만 하면 정적 분석이 활성화 된다. 유닉스상에서의 개발에서는 컴파일러에서 지정해 주고, makefile을 이용해서 빌드를 관리하지만, Xcode에서는 그래픽 환경(GUI)을 통해서 관리하기 때문에, 더 쉽게 컴파일러 옵션을 설정할 수 있다. 사용자 정의 빌드 세팅과 함께 사용할 경우, 거의 힘들이지 않고 모든 종류의 정적 분석을 사용할 수 ㅤㅇㅣㅎ있다. (사용자 정의 빌드세팅은 문서의 후반부에 다루기로 한다.)

작성하는 프로그램의 빌드 세팅을 설정해 보기 위해서 만들고 있는 Cocoa 프로그램이나 명령어 프로그램의 프로젝트 파일을 Xcode에서 열어 본다. 다음, (Groups & Files 아래부분에 있는)Target 부분을 연 다음, 컨트롤 클릭, 그리고 "Get Info" 메뉴를 선택해 준다. (그림1 참조)

그림1 타겟에 관한 정보 입수 화면

컴파일러에 옵션을 전달하기 위해서는, 옵션 설명 옆에 있는 체크박스를 선택해 주면 된다. (그림2 참조) 옵션을 제거하려면, 체크박스를 다시 선택해 주면 된다. 화면에 옵션이 나타나지 않으면, Other C Flags 나 Other Warning Flags 에 직접 기입하여도 된다.

그림2 컴파일러 옵션 활성화

가장 좋은 습관은 프로젝트 파일을 만든 후, 첫 코딩을 하기 전부터 경고 옵션을 켜 주는 것이다. 목표는 항상 모든 프로젝트 - 새로 만든 것이든 예전부터 만들던 것이던 - 컴파일러가 경고를 하나도 내뱉지 않는 코드를 작성하는 것이다. 오래된 코드를 가지고 그렇게 하기는 쉽지 않은 일이지만, 노력의 가치는 충분하다.

[편집] 언어 변종 세팅 사용하기

언어계열 옵션부터 살펴보기로 한다. (더 자세한 설명은 GCC 지침서 3.4절 "C 언어계열 옵션 설정" 부분을 참조하기 바란다.)

Xcode 에서 C 프로그램을 작성한다고 생각해 보자. 개발과정에서 C99 이전 계열의 GNU그리고 비GNU 계열과 호환이 되어야 한다는 사실을 알게되었다고 가정해 보자. 그럼, 코드 내에는 C99 관련된 언어의 특정기능을 사용하면 안 될 것이다.

기본으로 GNU89언어 계열을 따르도록 되어 있기 때문에, 이쪽 컴파일러에서는 코드가 잘 컴파일 될거라고 생각할 수 있을 것이다. 하지만, 꼭 그렇지 않다. 예를들면, 가변길이 자동 배열을 리스트3과 같이 사용했다고 생각해 보자.

리스트3 가변길이 배열

void processStr(const char *p) {
  char str[strlen(p) + 1];
  (void)strcpy(str, p);
  /*...*/
}

C99의 특성을 가지면서도 어째서 GNU89에서 컴파일이 되는 것일까? 답은 GNU89는 C89언어계열과 GNU C 확장기능까지를 포함하는데, 그 중 하나가 바로 가변길이 자동 배열이다.

코드가 C99 ISO를 따른다는 것을 확신하기 위해서는, GNU 확장기능이 포함된 C89 모드로 컴파일 되는 옵션을 꺼 주어야 한다. 다음과 같이 C 언어계열은 C89 [-std=c89]로 맞추어 주고, Pedantic Warning 체크박스를 선택해주고, Other Warning Flags에 -ansi 를 추가해 준다. (Pedantic 과 -ansi에 대해서는 아래부분에 더 자세히 나올 것이다.)

그림3a C언어 계열을 C89로 하고 Other Warning Flags에 -ansi를 추가해 줬다.

그림3b C언어 계열을 C89로 하고 Other Warning Flags에 -ansi를 추가해 줬다.

기억할 것은, GCC는 특정 언어 계열과 완전히 호환된다는 것을 보장하지는 않는 다는 것이다. (더 자세한 정보는 GCC 지침서 참고)

[편집] 경고수준 설정 사용

C 프로그램과 Objective-C 프로그램에서 진정한 의미의 정적 분석을 원한다면, GCC 의 경고설정을 사용하는 것이 첫번째 순서일 것이다. GCC 빌드 시스템에 특정 경고 설정을 전달하여, GCC가 수행하는 정적분석의 수준과 유형을 지정해 줄 수 있다. 기본적 검사에서 정밀분석까지 다양한 옵션이 있다.

특정 옵션이나 자세한 사용법에 들어가기 앞서, 다시 리스트2로 돌아가 보자. 이 예제가 바로, 적절한 정적 분석 옵션을 사용하지 않으면, 그냥 지나쳐 버리는 대표적인 코딩상의 문제이다. 정확한 옵션을 사용해 주면, GCC는 잠재적 문제에 대해서 경고를 해 준다. (그림 4a, 4b 참조)

그림4a GCC옵션이 안들어간 리스트4의 코드

그림4b GCC옵션이 들어간 리스트4의 코드

[편집] 경고의 단계

GCC가 제공하는 정적 분석을 도식화 하는 좋은 방법중 하나로, 단계별로 분류하는 것이다. (표1 참조) 단계에 따라,더 확실한 검사화를 통해 잠재적 문제가 없다는 확신을 더 주는 것이다. 안전이 제일 중요한 특정 프로그램의 경우에는 모든 단계를 다 해 봐야할 것이다. (검사 과정에 Splint도 포함해야 할 것이다.) 보통의 프로그램은 첫 몇단계만 해봐도 될 것이다.

참고 : Objective-C는 C언어의 상위개념이기 때문에, Objective-C 코드에서 언어에 종속적이지 않은 C 경고 옵션은 사용해도 무관하다. 일단은 C 옵션으로 시작해서, 나중에 Objective-C 옵션을 살펴볼 것이다.

Stage	Compiler Options	Description
1	-std=	Verify the language dialect to which you are writing.
2	-ansi -pedantic	Enforce extra language-level checks and compliance.
3	-Wall	Report the most common programming errors.
4	-Wall, -Wmost or -Wextra	Report the most common programming errors and less-serious but potential problems.
5	-Wno-div-by-zero -Wsystem-headers -Wfloat-equal -Wtraditional (C only) -Wdeclaration-after-statement (C only) -Wundef -Wno-endif-labels -Wshadow -Wlarger-than-len -Wpointer-arith -Wbad-function-cast (C only) -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wstrict-prototypes (C only) -Wold-style-definition (C only) -Wmissing-prototypes (C only) -Wmissing-declarations (C only) -Wmissing-field-initializers -Wmissing-noreturn -Wmissing-format-attribute -Wno-multichar -Wno-deprecated-declarations -Wpacked -Wpadded -Wredundant-decls -Wnested-externs (C only) -Wunreachable-code -Winline -Wno-invalid-offsetof (C++ only) -Winvalid-pch -Wlong-long -Wvariadic-macros -Wdisabled-optimization -Wno-pointer-sign	Provide additional checks not covered by -Wall -Wextra or -Wmost

표1 정적확인의 단계

[편집] 1단계 : 언어계열 옵션

1단계 옵션의 경우 특정 언어계열을 잘 준수하는지 확인하는 것이다. 대부분의 경우는 기본 언어에 맞게 컴파일할 것이다. 어떤 경우는 문제가 없지만, 미리 대상으로 하는 언어를 처음부터 컴파일러에 알려주는 것이 좋다.

참고 : C 프로그램의 경우 프로젝트를 생성한 경우 항상 언어계열을 지정해 주도록 한다. Objective-C (코코아기반) 프로그램의 경우에는 기본설정으로 충분하다.

이 단계의 효과는 대상으로 하는 언어에서 벗어나는 부분을 잡아주는 것이다. 기억할 것은 GCC가 C언어표준을 완전히 따른다는 것을 보장해 주지는 않는다는 점이다. 하지만, 기본점검으로는 충분히 좋다. (언어 계열과 다른 표준에 관한 예외사항에 대해서는 GCC 지침서를 참고하기 바란다.)

[편집] 2단계 : 언어계열옵션에 더해 호환 검증

2단계에서는 더 엄격한 언어계열 확인을 한다. -ansi와 -pedantic 옵션을 사용해서 (Pednatic Warning은 인터페이스에서 가능하다) GCC 언어 계열 호환에 대해서 더 엄격히 검사한다.

아다시피, GCC 언어계열중 몇몇은 GNU 언어확장 (GNU89, GNU99)를 지원한다. 엄격한 ISO 언어 호환이 필요없다면 문제가 없다. 하지만 필요하다면, 언어계열 세팅과 같이 -ansi 와 pedantic 옵션을 사용할 수 있다.

-ansi 옵션은 해당 언어계열의 모든 GNU 확장기능을 제거해 준다.그 결과로 원치않는 GNU 확장에 영향을 받지 않는 ISO 계열의 프로그램을 작성할 수 있다. -pedantic 옵션의 경우 더 범위를 확장시킨다. -ansi 옵션과 같이 -pedantic 옵션을 사용하는 경우 특정 언어와 호화되지 않는 확장뿐 아니라 모든 GNU 확장을 금지시킨다.

-ansi 와 -pedantic 을 같이 사용하면, 원하는 언어 계열에 딱 맞출수 있다. 이 단계의 효과는 언어 계열 호환을 위한 더 엄격한 확인이다.

[편집] 3단계, 4단계 : 일반적거나 조금 들 일반적인 프로그램 오류보고

가장 많이 쓰이는 경고 옵션은 -Wall 과 -Wextra/-Wmost 이다. 이 옵션들은 여러 옵션을 한데 뭉쳐 놓은 옵션이다. Xcode에서는 원래 이 옵션이 켜져있지 않기 때문에, Other Warning Flags에서 직접 지정해 주어야 한다.

-Wall 옵션은 대부분의 일반적인 프로그래밍 오류에 대해서 보고를 해 준다. 항상 문제가 있는 구문이라 주의가 필요한 부분을 알려준다. 이 옵션을 통해서 경고 메시지가 나오면, 심각히 생각하고 반드시 고치는 것이 좋다. 일반적으로 대부분의 빌드에서 이 옵션을 사용하는 것이 좋다고 한다.

-Wextra 옵션은 들 심각한 문제점을 알려준다. (예전 버젼의 GCC에서는 -W 로 쓰였다. 현재 버전에서도 -W 을 지원하기는 하지만, -Wextra를 쓰기를 권장한다.) 기술적으로는 오류가 아니지만, 확인하지 않고 놔두면 문제로 발전할 가능성이 있는 부분을 알려준다.

예를 들면, 리스트4에 있는 코드를 -Wall 옵션을 켜도 경고가 나오지 않는다. 하지만, -Wextra 옵션을 쓰면, 문제가 발견이 된다.

리스트4 -Wall 옵션을 사용하여 컴파일 한 코드

void checkVal(unsigned int n) {
  if (n < 0) {
    /* Do something... */
  }
  else if (n >= 0) {
    /* Do something else... */
  }
}

-Wextra -Wall 모두 표준 GCC 옵션으로 다른 플래폼의 컴파일러에서도 사용이 가능하다. 하지만, -Wmost 옵션은 애플이 만든 것으로 -Wall과는 동일하지만, -Wparentheses를 뺀 것(-Wno-parenthese)이다.

많은 개발자들이 -Wextra 옵션을 사용하는 것에 대해 뒤섞인 반응 보이고 있다. 왜냐하면, 어쩔수 없는 부분까지 찾아내기 때문이다. 권장사항은 항상 이 옵션을 사용하고, 코드를 만들기 전에 항상 먼져 활성화 시켜 놓으라는 것이다. 개발과정에서 미리 문제가 발생할 지점을 알고 있는것이, 나중에 가서 문제점을 그냥 지나쳤다는 것을 아는 것보다 낫기 때문이다.

[편집] 5단계 : 더 엄밀한 검사를 하는 옵션들

-Wall -Wextra/-Wmost 보통의 프로그램을 위한 알맞은 검사를 제공한다. 하지만, 코드에 대한 확신을 높이기 위한 다른 옵션도 GCC에는 존재한다.

리스트5에서는 4단계에서는 경고를 발생하지 않는 Objective-C 프로그램을 보여준다.

리스트5 : 4단계옵션에서 Objective-C 프로그램

// main.m
#import 
#import "ClassA.h"

int main(void) {
  ClassA *obj = [[ClassA alloc] init];
	
  double x = 10.0;
  double y = 11.0;
  double z = 0.0;
	
  z = [obj process:x :y];
  (void)printf("%lf\n", z);
  
  [obj release];	
  return 0;
}

// ClassA.h
#import 

@interface ClassA : NSObject {
}
-(double) process:(double)x: (double)y;
@end

// ClassA.m
#import "ClassA.h"

@implementation ClassA
- (id) init {
  self = [super init];
  return self;
}
- (void) dealloc {
  [super dealloc];
}
-(double) process:(double)x: (double)y {
  double z = 0.0;
  if (x == y) {
    z = x * y;
    return z;
  }
  else {
    z = x * y;
    return z;
  }
  z = x - y;
  return z;
}
@end

정적검사가 정말 도움이 될 수 있는 부분이다. 더 검사를 하기 위해서 -Wfloat-equal과 -Wunreachable-code 옵션을 Other Warning Flags에 추가해 준다. 5단계인 이 검사는GCC가 제공하는 가장 완결된 검사를 제공한다. (그림5 참조)

그림5 리스트5에 대한 5단계 정적분석 결과

[편집] 다른 옵션들

언어계열 옵션과 경고 옵션 이외에, GCC에서는 어떻게 경고와 오류정보가 표시할 것인지에 대한 옵션이 있다.

Compiler Options	Description
-fsyntax-only	Check for syntax errors only and do not compile or build code.
-pedantic-errors	Report all pedantic warnings (-pedantic) as errors.
-w	Disable all warning messages.
-Wfatal-errors	Abort the compilation on the first error.
-Wsystem-headers	Report warning messages found in system header files.
-Werror	Report all warnings as errors.

표2 표시 옵션

[편집] Objective-C 옵션들

Objective-C 코드를 검사하기 위해서 C 언어 독립적인 옵션을 사용해도 되지만, GCC에서는 Objective-C 언어만을 위한 옵션을 제공하고 있다.

객체지향 프로그래밍에서는 상속자가 구현해야 하는 인터페이스를 정의해 놓는 것이 흔한 일이다. 인터페이스는 구현을 포함하지는 않고, 구현이 필요한 공간만 확보해 놓는다.

Java 코드에서 이와 같은 것을 원한다면, Interface를 이용하면 된다. C++에서는 추상클래스, Objective-C에서는 protocols를 통해서 제공한다. 특정 프로토콜에 따르는 클래스는 선언한 모든 메서드를 반드시 구현해야 하는 공식프로토콜(Formal Protocol)과 구현해야 하는 메서드의 목록을 보여주지만 반드시 강제하지는 않는 약식프로토콜(Informat Protocol) 2가지 종류의 프로토콜이 있다.

리스트6에서는 프로토콜과 그것에 따라 구현한 클래스의 예제가 있다.

리스트6 : 프로토콜과 그것의 구현

// MyProto.h
@protocol MyProto
  -(void) doThis;
  -(void) doThat;
@end

// ClassA.h
#import 
#import "MyProto.h"

@interface ClassA: NSObject  {
}
-(void) doThis;
-(void) doThat;

@end

// ClassA.m
#import "ClassA.h"

@implementation ClassA

-(void) doThis {
  (void)printf("ClassA:doThis\n");
}
-(void) doThat {
  (void)printf("ClassA:doThat\n");
}
@end 

MyProto 는 메서드의 목록을 정의해 놓은 공식프로토콜이다. MyProto에 따르고 싶은 ClassA와 같은 클래스는 반드시 모든 메서드를 구현해야 한다. 기본 Cocoa 응용 프로그램 설정에서는 GCC는 어떠한 경고도 보이지 않는다.

이제, 리스트 7, 그림6과 같이 구현을 확장한다고 생각해 보자.

리스트7 ClassB 구현을 확장하는 코드

// ClassB.h
#import 
#import "ClassA.h"

@interface ClassB : ClassA  {
}
@end

// ClassB.m
#import "ClassB.h"

@implementation ClassB
@end

그림6 MyProto 프로토콜과 그 구현

이 코드를 컴파일 하면 4개의 연관된 경고가 나온다. (그림7 참조)

그림7 : ClassB 빌드와 관련된 컴파일러 경고

기본적으로 Incomplete Objective-C Protocol Warn 옵션이 켜져 있기 때문에 이 경고가 보여지는 것이다. 이 옵션을 통해서, 프로토콜이 원하는 메서드가 구현되어 있지 않을 때, 경고를 나타내도록 하는 것이다.

문제는 ClassB는 스스로 구현하지 않고, 상위클래스(ClassA)로 부터 프로토콜 메서드의 구현을 상속받았다는 것이다. 이 문제를 해결하는 방법은 이 옵션을 끄는 것이다. 하지만, 그렇게 되면 진짜 문제 있는 프로토콜의 문제점도 보고하지 않을 것이다. (더 자세한 정보는 GCC 지침서의 3.6절 "Objective-C와 Objective-C++ 계열 옵션 설정" 편을 참조하기 바란다.)

[편집] 프로젝트에서 정적분석 사용하기

GCC와 Xcode에서 C, Objective-C 코드를 위한 정적분석을 배웠으니, 실제 사용해 볼 차례다. 1단계에서 5단계까지 확인해 볼 간편한 방법이 필요한데, Xcode의 Targets와 Build Configuration을 사용하면 편리하다.

Target이란, 소스코드, 헤더파일, 라이브러리, 빌드세팅 컴파일러 옵션, 파일처리방법등을 가지고 있는 일종의 고차원의 설계도라 생각하면 된다. build configuration은, 특정 Target에 포함될 빌드세팅 값의 모음을 이름짓는 방법이라 생각하면 된다. build configuration을 통해서, 하나의 코드만 가지고 각 프로젝트마다 여러개의 Target을 만들지 않고 빌드 방법을 바꿔볼 수 있다. 하나의 Target, 각 단계별 여러개의 build configuration을 가질 수 있는 것이다.

build configuration을 만들려면, (Groups & Files 아래에 있는) Target 을 선택하고, 컨트롤 클릭한다음, Get Info를 선택한다. Target Info 창에서, Build 탭을 선택하고 Configuration 메뉴에서 Edit Configuration을 선택해 준다. (그림8a, 8b 참조)

그림8a build configuration 만들기

그림8b build configuration 만들기

새로운 빌드 세팅을 만들려면, 현재 있는 세팅(예를들면, Debug)를 선택한 다음, Duplicate를 눌러준다. 이름을 적절히 바꿔준다음, Target Info에서 Configuration메뉴에서 새로 만든 Build Configuration을 선택해 준다. 원하면 세팅값을 바꿔준다. (그림9a, 9b 참조)

그림9a 새로운 빌드세팅값

그림9b 새로운 빌드세팅값

새로운 빌드세팅을 사용하려면, Build Results 창(Window > Tools > Build Result)을 연 다음, Active Build Configuration에서 원하는 것을 선택해 주고, 프로젝트를 빌드한다. (그림10 참조) (Active Build Configuration메뉴가 나타나지 않는다면 툴바에 메뉴를 추가해 주어야 한다.)

그림10 새로운 빌드세팅 적용

Xcode는 프로젝트 빌드에 이 값을 사용하게 된다.

[편집] 결론

이 문서는 정적분석을 이용해서 할 수 있는 것의 작은 부분만을 다루었을 뿐이다. 희망적인 것은, GCC의 정적 분석 옵션과 개발과정에 정적분석 기법에 관해 충분히 흥미를 자극했을 것이라는 것이다. GCC의 언어계열, 경고 옵션 사용과 Xcode의 직관적인 인터페이스를 통해서 적은 노력으로 코드의 품질향상을 누릴 수 있다. 더 많은 점검을 원한다면 Splint를 사용해 볼만하다.

[편집] 더 많은 정보

• GCC, the GNU Compiler Collection
• ADC GCC 지침서(4.0.1)
• Xcode 빌드 세팅 사용하기
• Safer C: Developing Software for High-Integrity and Safety-Critical Systems by Les Hatton (McGraw-Hill, 1995).
• Expert C Programming by Peter van der Linden (Prentice Hall PTR, 1994).
• Lint, a C program checker by Stephen Johnson (Computer Science Technical Report 65, Bell Laboratories, December 1977).
• The splint.org website.

출처 : http://developer.apple.com/tools/xcode/staticanalysis.html (2006-07-10) 번역 : wangsy (2006-11-07)