썰렁한 엔지니어

indent라는 C 소스의 들여쓰기, 띄어쓰기 괄호 위치 등을 정리해주는 프로그램은 의외로 오래된 프로그램 중의 하나이다. 1988년의 오래된 이메일 http://www.pell.portland.or.us/~orc/Code/bsd/bsd-current/indent/ 를 보면, 원작은 David Willcox가 일리노이 대학교에서 어떤 프로젝트로 인해 필요해서 만들었고, 그 이후 여기 저기 떠돌다가 4.2 BSD에 처음 들어왔다고 한다. 그러나, linux에는 그 소스의 최신(?) 수정본이 들어 있다. 최신이래봐야 2002년 버전인데, 지금쯤 C++이 적절히 반영된 최신버전이 들어옴직한데, 뭘 고민하는지 그간 업데이트가 없다. indent는 여러 옵션을 가지고(실로 엄청난 옵션이다.) 수행되는데 이 옵션들..

아래는 Cascading Style Sheet - The Designer's Edge (Holzschlag) 라는 책의 한 부분을 인용한 것이다. 저자에게는 허락을 받지 않았으나, 미안하긴 하지만 게재한다.아래는 의역입니다. So why should you follow standards? A lot of people say, “Hey, I can use nonstandard markup that works just fine.” 그러면 왜 표준을 지켜야하는가. 많은 사람들이 말하길 "뭐, 난 표준이 아닌 태그를 이용해도 잘 돌아가."라고들 말한다. There are several reasons why understanding and following standards makes sense. Here are..

온갖 상상이 난무하고, 추측과 확신이 교차하는 작업이 디버깅이라고해도 과언이 아니다. 디버깅은 아는 것 만큼 혹은 조금 더 상상한 것 만큼만 해결 가능하고, 그 외의 것들은 모두 우연한 실수일 뿐이다. 어쩌다 문제를 해결했어도 그것은 실수로 해결한 것이리라. 잔인한가? 디버깅이야말로 책으로 보아왔던 지식이 살아나는 현장이고, 디버깅이야말로 책을 들여다보게 만드는 작업이다. 디버깅을 하면서 가장 중요한 자세 하나를 생각해보고자 한다. 디버깅의 가장 큰 적은 "그 부분은 문제없을텐데"라고 믿게되는 근거를 알 수 없는 자기확신이다. 만일 디버깅을 잘하고자한다면, 지금까지 확실하다고 생각했던 부분을 다시 한 번 보라. 프로그래머가 가져야할 가장 중요한 덕목 중에 하나는 논리적인 무결성과 실제 데이터의 무결성에 ..

요즘에야 프로젝트의 시작부분에 설치본을 만드는 것이 당연하다 생각되나, 나 자신도 몇년전에는 그러하다 생각지 못하였는데, 그 이유는 "설치할 것이 있어야 설치본을 만들지!"라는 생각에서였다. 하지만, 제일 쉬우면서도 가장 오래, 배포되는 프로그램의 끝까지 애를 먹이는 것이 바로 배포를 위한 설치본, 또는 부분패치 설치본이며, 이것은 릴리즈 엔지니어링의 마지막 결과물에 해당한다. 강조를 백번해도 모자랄 정도로 프로젝트의 시작부분에서의 설치본인데, 이것은 개발조직이 분화되기 위한 첫걸음이된다. 개발초기부터 테스팅 및 릴리즈를 위한 얘기를 할 수 있고, 중간 단계쯤에서 그간 진행된 기능에 대한 다양한 피드백을 받을 수도 있고, 나중에 고생할만한 일을 초기에 잡을 수 있는 아주 필수적인 것이 개발팀이 설치본을 ..

Subversion : http://subversion.tigris.org/ TortoiseSVN: http://tortoisesvn.tigris.org/ poedit: http://www.poedit.org/translations.php 나는 요 세가지의 한국어 문자열을 관리하고 있는데, 어떤 소프트웨어가 맘에 들면 번역을 시도해보는 것은 그 프로그램을 깊이 이해하는데 더 도움이 된 것 같다. 가장 활발히 하는 것은 TortoiseSVN인데, 그 이유는 일주일에 한 번 씩 번역 상태가 메일로 오고 각 언어별 번역율이 그래프로 나오는 것이 약간의 경쟁을 유도하게한다. subversion은 일주일에 한 번정도 모든 언어들의 번역상태가 메일링리스트로 전송되어 온다. Translation status repo..

$ cat a.c #include int noinit_global_var; int init_global_var = 0; static int static_var; static int init_static_var = 0; int func() { static int func_static_var; return 0; } $ gcc -c -o a1.o a.c $ g++ -c -o a2.o a.c $ nm a1.o 00000000 T func 00000008 b func_static_var.0 00000000 B init_global_var 00000004 b init_static_var 00000004 C noinit_global_var 0000000c b static_var $ nm a2.o 00000000 T ..

[CODE]char ch; while( (ch = fgetc( f )) != EOF ) { printf("%c", ch ); }[/CODE] 언뜻보기에는 맞는 것 같이 보인다. 하지만, 여기에는 isprint 못지 않은 두려운 버그가 숨어 있다. fgetc 의 원형은 다음과 같다. [CODE]int fgetc( FILE * );[/CODE] fgetc의 return 값이 int 란다. 그리고, 문자하나를 되돌리는 함수라니.. 각설하고 위 코드는 다음과 같아야한다. [CODE]int ch; while( (ch = fgetc( f )) != EOF ) { printf("%c", (char) ch ); }[/CODE] fgetc의 설명을 보면, 파일의 끝이나 오류를 만났을 때 EOF를 되돌린단다. unsign..

char ch = 'X'; 위와 같이 되어 있을 때, 다음과 같이 사용하는 것이 옳은 것이냐하는 것인데, if( isprint( ch ) ) { blah; } 경고감이다. 왜냐하면, isprint의 원형은 [CODE]int isprint (int c);[/CODE] 이기 때문이며, 여기에는 isprint에 넣는 인자의 철학과 우리가 흔히 사용하는 문자형 변수의 차이에서 오는 괴리감이 있는 것이다. int 는 char가 표현할 수 있는 것보다. 일반적으로 더 많은 범위를 받을 수 있는데 (sizeof( char ) == sizeof( int ) 인 구조를 제외하면 항상 그렇지 않는가?) 그러면서도 signed 형이라는 것이다. 그런데, char 는 명시적으로 signed char, unsigned char..

* GNU GCC versus Sun's Compiler in the SPARC Platform ::http://www.osnews.com/story.php?news_id=5830&page=3 * Are 64-bit Binaries Really Slower than 32-bit Binaries? ::http://www.osnews.com/story.php?news_id=5768 * Solaris 64-bit Developer's Guide ::http://docs.sun.com/app/docs/doc/806-0477 * Compiler Usage Guidelines for 64-Bit Operating Systems on AMD64 Platforms ::http://www.amd.com/us-en/ass..

함수의 프로토타입을 꼼꼼히 분석하라 : 함수의 프로토타입에는 그 함수가 뭘하는 것인지에 대한 정보의 90%가 들어 있다. const 형식이 어떤 것인지 모두 이해하고 있어라 : 함수 인자, 변수 선언, 멤버 함수 맨 뒤. static 형식이 어떤 것인지 모두 이해하고 있어라 : 변수 선언, 함수 선언, 멤버 함수 오브젝트 파일안에 뭐가 들어 있는지 알고 있어야한다. : nm, objdump, readelf, dumpbin.exe, depends.exe 등의 유틸리티가 도움이 된다. 소스를 코딩하고나면 오브젝트 코드가 어떻게 생기는지 알고 있어야한다. 스택에 쌓이는 순서를 상상하라 커널레벨과 사용자레벨의 차이와 그 전환은 어떻게 일어나는지 알고 있어야한다. 디버깅 툴(브레이크 포인트, 변수 내용 보기, 시..