|
블로그에 쓴글을 붙여 넣고 보니 글모양새도 하나도 맞고
그림도 이상하고 난감하군요. 혹시 다른곳에 복사해가시려면 제
블로그에
있는것을 참고 하세요. 오타도 많이 보이는데 수정하겠습니다.
static_cast와 c type의 강제 cast의 장단점은 익히들 알고 있을 것이다. 다들 static_cast를 써라라고 강조 한다.
코드 작성자 입장에서는 별로 차이점이 없는데 static_cast를 사용하는 이유는 여러가지가 있겠지만, 런타임시에 발생할 수 있는
오류를
컴파일 타임에 잡아내 줄수 있다는게 하나의 이유일 수도 있다.
서로 casting 할 수 상황의 것인 경우 c type의 cast는 버그의 가능성을 만들어 주지만 static_cast는 안전하게
casting 해주거나
컴파일 타임에 오류를 낸다.
call by reference 방법으로는 reference를 쓰는 방법과 pointer를 쓰는 방법이 있다. 사실 문법적인
모양새나 그동안에 관습적으로
쓰임을 선택하곤 하는데, 어떻게 보면 워낙 기초적인 부분이다라고 생각할 수 있지만, 코딩의 신념이나 자신만의
코딩컨벤션을
가지고 있지 않으면 두개사이에서 사용함의 망설임을 갖게 되는 경우가 있다.
오리지널 C 시절부터 의례 값이 변경되는 call by reference는 포인터를 이용했으므로 값이 변경되는 OUT 인자일경우 포인터로
선언을 하고, reference는 구조체등의 인자 전달시 space complexity에 이윤을 남기기 위해서 쓴다라고 기술되어 있는 책도
있고,
어떤것은 포인터의 단점을 나열하며 주로 reference를 써라 라는 아티클도 있다.
#define OUT
void foo(OUT Obj& a)
{
a++;
}
void main()
{
Obj a(0);
foo(a);
printf("%d", a.value);
}
저런 경우에 foo 함수의 인자는 call by reference라는 것을 OUT을 통해서 알려줬으므로 관습적인 부분에 어느정도 면죄부가
있다고 하겠다. 그리고, pointer를 넘김에 비해 reference는 반드시 초기화를 해줘야 한다는 조건이 있기 때문에 NULL 체크정도는
안해도 되는 간편한 장점도 있다. 하지만 훗날 가독성을 위해서 포인터를 써라, 흠, 이래서 갈팡 질팡 하게 되는 경향이 있었던것 같다.
저렇게 OUT과 같이 주석은 아니지만, 함수 사용자에게 흰트를 주는 것을 Annotation 이라고 한다.
C에서 문자열은 단순히 마지막에 NULL 체크에 의지하고 있기 때문에 버퍼오버런을 발생시킬 요지가 많다. 그리고 이런 버퍼
오버런
발생은 꼭 릴리즈 후에 치명적인 일이 있게된 후에 알게 된다.
문자열 관련 함수를 살펴 보면 이러한 버퍼오버런에 취약한 형태로 선언된 함수들이 많다. 다음의 strcpy 같은경우는 받는 버퍼의
크기가
작은경우 문제가 발생된다.
char *strcpy(char *strDestination, const char *strSource);
그래서 다음과 같은 안전한 스트링 처리 함수 형태가 등장했다. (strsafe함수에 대해서는 신영진님블로그에 깔끔한 강좌가
있다.) STRSAFEAPI StringCchCopy(STRSAFE_LPSTR pszDest, size_t cchDest, STRSAFE_LPCSTR pszSrc);
프로그래머 입장에서는 버퍼의 사이즈를 명시해서 한번 더 각성하게 되는 효과가 있다.
이것을 흉내내어 다음과 같은 스트링값을 버퍼에 채워주는 함수를 만들었다고 가정해 보면,
void FillChar(TCHAR* buffer, int cchBuf, TCHAR c)
{
for(int i = 0; i < cchBuf; ++i)
buffer[i] = c;
}
그리고 다음과 같이 잘못 사용했다고 가정해 보자. TCHAR* buf = (TCHAR*)malloc(128 * sizeof(TCHAR));
FillChar(buf, 256, 'a');
위화면과 같이 비주얼 스튜디오 2005에서 Warning level 4로 하고 컴파일을 한다고 하더라도, 이 함수에 대한 아무런 경고를
주지
않는다. 결국 릴리즈 후 문제 발생한 다음에야 관련 버퍼를 검색하다가 수정이 될 확률이 높아 진다.
StrSafe.h에 있는 함수들 처럼 깔끔하게 함수 설계를 한다면야 좋겠지만, 프로그래밍을 하다 보면 함수라는게 처음 마음먹은
형태대로만 선언의 모양새를 갖추는것은 어렵다.
그리고 무한정 방어코딩을 해줄수도 없는 노릇이다. FillChar이란 함수는 cchBuf값만 문제없다면 오케이인 간단한 기능을 하기
때문이다.
Standard Annotation Language를 사용하면 cchBuf값을 컴파일 타임에 검사해 줄 수 있을 뿐 아니라
여러가지의 다양한 버퍼를
다루는 검증을 컴파일 타임에 수행해 줄 수 있다. 위에서 예로든 cchBuf값을 컴파일타임에 검사하는 SAL을 적용하면
다음과
같이 함수에 Annotation을 추가할 수 있다.
#include <sal.h>
void FillChar(__out_ecount(cchBuf) TCHAR* buffer, int cchBuf, TCHAR c)
{
for(int i = 0; i < cchBuf; ++i)
buffer[i] = c;
}
그런데 요걸 컴파일 하려면 몇가지 준비해야 될 것들이 있다. 함께 설정해 보도록 하겠다.
먼저 Visual Studio 2005 Team Foundation이 필요한데, 대부분의 Visual Studio 2005 사용자는
2005 team suite 혹은 professional
단일버전이 깔렸을 것인데, 그렇다면 SDK for Vista가 필요하다. 아마 대부분의
개발자라면 SDK for Vista가 깔려 있을 것이라 생각된다.
처음 SDK for Vista를 설치했다면 그 다음 Visual Studio에서 SDK의 path 설정을 해 주어야 한다.
Tools - Options - Projects and
Solutions - VC++ Directories에 설치된 SDK가 가장 윗쪽에
반영되도록 올려주어야 하는데, 일일이 수동으로 설정 해주지 않아도 된다.
윗 그림에 있는 배치파일을 실행하면 자동으로 셋팅해주므로, 예전 SDK 깔고 수동으로 적어서 올려줬던 노가다는 하지 않아도 된다.
그담, Project 옵션에서 SAL을 활성화 시키는 옵션을 주어야 하는데 지금 pc가 Team Foundation이 아니라서,
옵션에 나와있는 UI
스샷은 찍지 못하고, Professional이라면 화면에서 처럼 옵션을 Command Line에 넣어 주면 된다. 어짜피
컴파일이란 작업은 IDE가
cl.exe 에 옵션들을 인자로 넣어 주기만 하는것이므로 cl.exe만 /analyze를 인식한다면 상관없다.
만일 다음과 같은 9040 Warning이 뜬다면 화면과 같이 Executable Path를 추가 설정해 준다. 윗 문장에서 넌즈시
얘기 했지만
professional 버전의 cl.exe는 /analyze 옵션을 인지 하지 못한다. Vista SDK에 있는 cl.exe를
사용하기 위한 작업이다.
cl : Command line warning D9040 : ignoring option '/analyze'; Code Analysis warnings are not available in this edition
of the compiler
C:\Program Files\Microsoft SDKs\Windows\v6.0\VC\Bin
이제 위에 마련된 소스를 컴파일 해보면 3개의 warning이 뜬다. 잘못된 부분을 제대로 짚어 주고 있다.
1>c:\documents and settings\yhkim\my documents\visual studio 2005\projects\testtest\main.cpp(13) : warning C6057:
Buffer overrun due to number of characters/number of bytes mismatch in call to 'FillChar'
1>c:\documents and settings\yhkim\my documents\visual studio 2005\projects\testtest\main.cpp(13) : warning C6386:
Buffer overrun: accessing 'argument 1', the writable size is '128*sizeof(TCHAR)' bytes, but '512' bytes might be written: Lines: 12, 13
1>c:\documents and settings\yhkim\my documents\visual studio 2005\projects\testtest\main.cpp(13) : warning C6387:
'argument 1' might be '0': this does not adhere to the specification for the function 'FillChar': Lines: 12, 13
워닝만 해결한다면 FillChar은 나름대로 효율적이고 안전하게 쓰였다고 할 수 있겠다.
/analyze 옵션과 관련해서 수십개의 새로운 warning을 다음링크에서 추가로 볼수가 있다. 원하지 않는 Warning이 있다면
전처리기로
끄면 되겠다.
http://msdn2.microsoft.com/en-us/library/a5b9aa09(VS.80).aspx
SAL에 대한 가장 좋은 메뉴얼은 sal.h에 앞부분에 기술되어 있는 주석이다. 시간을 내어 자세히 살펴 보면 매우 유용한
매크로들을
발견할 수 있고, assert처럼 계속적으로 사용하려는 습관을 들이는 노력을 해야 한다.
__in 과 같은것을 사용하면 앞서 말했던 reference의 장점을 그대로 가저가면서 관습대로 point를 유연하게 사용할 수 있다.
마지막으로, strsafe.h 에 정의된 StringCchCopy를 다시 살펴 보면 다음과 같이 되어 있다.
STDAPI StringCchCopy( __out_ecount(cchDest) LPTSTR pszDest,
__in size_t cchDest,
__in LPCTSTR pszSrc
);
각 인자들 앞에 SAL과 같은 Annotation이 붙어 있다. Windows Vista에서 strcpy 같은 불안한 함수를 사용하지 않고
이렇게 SAL을
사용했을 경우 기존의 버퍼오버런 에러율을 84%나 감소시킬수 있었다고 한다. 이것은 strsafe.h에 있는 함수를 적극
사용하라는
이유중 하나가 되기도 하다.
|