Shinnara's Blog
Talking with Shinnara :: NaraTalk.com

 자칭 타칭 '소프트웨어 개발자'인 나에게 있어 프로그래밍은 관심의 대상이 아닐 수 없다. 또한 대학원에서 '소프트웨어 공학(Software Engineering)'을 전공한 나에게 프로젝트의 성공적인 수행, 문제가 적은 소프트웨어의 개발 등은 최대의 관심사가 되곤 한다.
 
  최근 들어 다시금 들여다보고 있는 분야 중에 하나가 Static Analysis 이다. 지금 수행하고 있는 프로젝트에서는  작성된 코드에 대해 Code Walkthrough( 모든 코드에 대해서 하는 건 아니지만), 테스트 자동화 도구를 이용한 Unit Test ( 임베디드 환경이라 도구 값이 장난이 아니다.), Verication Test 를 수행하고, 시험팀에 Delivery 를 마치고 나면 시험팀은 각 릴리즈별로 시험을 진행하게 된다. 이러한 과정을 거치면서 다양한 버그들이 발견되고, 수정되어 소프트웨어에 잔존하는 결함의 수는 나날이 줄어간다. 운영중 결함은 엄청난 파장을 일으키는 분야에서 일하고 있기 때문이기도 하지만, 소프트웨어의 결함을 줄이는 것에 많은 노력이 들어가곤 한다.
 이렇듯 많은 테스트를 진행하지만, 테스트는 테스트일 뿐. 소프트웨어 자체의 무결성을 증명하기는 어렵다. 소프트웨어 테스팅에서 항상 나오는 이야기다. '버그 없는 소프트웨어'는 존재할 수 없다는 혹자의 말처럼 Defect-Free 를 달성하기는 어렵겠지만, 그래도 그 결함의 가능성을 조금이나마 낮출수 있고, 그 노력이 그다지 힘들지 않다면 적용하고 싶은게 내 생각이다.
 
  얼마전 대전의 리베라 호텔에서 PolySpace 런칭 세미나가 있었다. MathWorks 가 PolySpace 를 인수하고, 2008년 본격적인 영업을 시작하기 위한 첫 행사였다. 이벤트의 성격이 강한지라, 프랑스의 엔지니어가 약 세시간에 걸쳐 프랑스 필이 강한 영어( Frenglish ?)로 Polyspace 에 대한 설명은 진행하였다. PolySpace 는 Static Analysis 를 통해 RunTime 에서 발생할 수 있는 에러를 사전에 검출하고자 하는 도구로, 꽤나 고가였다. 쉽사리 도입을 논하기 어려운 도구였는데, 그 세미나에서 얻은 것이 있다면 PolySpace 가 비교 대상으로 삼은 다양한 툴들에 대한 정보였다. 그중에 하나가 Lint.
 
 오늘 찾아본 자료는 Splint ( Secure Programming Lint : http://www.splint.org/ )이다. 아직 자세한 내용은 잘 모르겠지만, User's Manual 의 첫부분에 아래와 같은 설명이 나온다.

Splint is a tool for statically checking C programs for security vulnerabilities and programming mistakes. Splint does many of the traditional lint checks including unused declarations, type inconsistencies, use before definition, unreachable code, ignored return values, execution paths with no return, likely infinite loops, and fall through cases. More powerful checks are made possible by additional information given in source code annotations. Annotations are stylized comments that document assumptions about functions, variables, parameters and types. In addition to the checks specifically enabled by annotations, many of the traditional lint checks are improved by exploiting this additional information.

소스 코드에 존재하는 일명 Bad-Smell ( from 'Refactoring') 을 찾아 주며, Annotation을 이용해 좀더 강력한 검사를 수행할 수 있다고 한다.

Splint 를 사용해보기 위해, 테스트 머신인 Solaris 장비에 설치를 하였다. Splint 에서 SunOS 용 Binary 배포본을 지원하기 때문에 다운받아서 압축을 푸는 것 만으로도 설치를 수행할 수 있었다.

앞으로 Splint 를 사용하면서 얻게되는 다양한 정보를 함께 공유해보고자 한다.


p.s. binary 로 설치를 했어도 아래와 같이 환경변수를 설정해주어야 제대로 작동합니다.

export SPLINT_HOME=/home/hkshin/Programs/splint-3.1.1
export LARCH_PATH=$SPLINT_HOME/lib
export LCLIMPORTDIR=$SPLINT_HOME/imports


 

이올린에 북마크하기(0) 이올린에 추천하기(0)

#include <math.h>

	main()

	{ int i;

	   printf("\t Number \t\t Square Root of Number\n\n");

	   for (i=0; i<=360; ++i)
            printf("\t %d \t\t\t %d \n",i, sqrt((double) i));
	}

위의 프로그램을 컴파일하고 제대로 실행하라는 문제군요. 라이브러리를 어떻게 쓰는지에 대한 문제입니다.

위의 내용대로 코드를 입력하고 컴파일을 해봅니다.

[shinnara ~/work/c/unixc]$ gcc exer12172.c
/var/tmp//ccEk6OYt.o(.text+0x4a): In function `main':
: undefined reference to `sqrt'
[shinnara ~/work/c/unixc]$

역시나 sqrt 가 정의되어 있지 않다고 나옵니다. -l 옵션을 붙여줘야 합니다. 

[shinnara ~/work/c/unixc]$ gcc exer12172.c -lm
[shinnara ~/work/c/unixc]$

gcc 옵션과 관련된 자세한 내용은 Gcc 와 Make 강좌를 참조하시기 바랍니다.

컴파일이 제대로 되었으니, 이제 실행을 해봐야 할텐데요. a.out 이 디폴트로 생겼으니 실행을 해봅니다.

[shinnara ~/work/c/unixc]$ ./a.out
         Number                  Square Root Of Number

         0               0.00
         1               1.00
         2               1.41
...
         353             18.79
         354             18.81
         355             18.84
         356             18.87
         357             18.89
         358             18.92
         359             18.95
         360             18.97
[shinnara ~/work/c/unixc]$

그런데 실행된 모습이 다르다구요? 네, 맞습니다. 위의 프로그램을 조금 변경했습니다. 아래는 제 소스입니다.


[shinnara ~/work/c/unixc]$ cat exer12172.c
#include <math.h>

main()
{
    int i;

    printf("\t Number \t\t Square Root Of Number\n\n");

    for(i=0;i<=360;i++)
        printf("\t %d \t\t %.2f\n",i,sqrt((double) i ));
}
[shinnara ~/work/c/unixc]$


이제, 다들 제대로 동작하시죠?

이올린에 북마크하기(0) 이올린에 추천하기(0)