Code name R

오늘 개발을 하다가 디버깅 메시지를 심고 컴파일을 한 뒤 수행을 해보았는데 순서가 보장되지 않는 일이 일어났다.
예제 코드는 아래와 같다.

int main()
{
    fprintf(stdout, "[DEBUG] debug1");
    fprintf(stderr, "print1\n");
}

결과는 아래와 같다. 예상한대로인가? 나는 당연히 디버그 메시지가 먼저 나오리라 생각했는데...

아래는 위와 같은 문제를 해결한 코드이다.

int main()
{
    fprintf(stdout, "[DEBUG] debug1\n");
    fprintf(stderr, "print1\n");
}

결과를 보자

이제 의도한대로의 결과물이 나왔다. 머가 바뀐것인가? 두개의 코드를 비교해보면 달랑 '\n'이 추가되었다.
이런 현상이 발생한 원인은 stdout과 strerr의 차이에서 비롯된다.

다시 작성한 코드에서는 개행문자인 '\n'을 만났기 때문에 의도한대로 출력이 된 것이라고 보인다. fflush 함수를 통해 해결할 수도 있지만 내가 의도한데에는 개행문자만으로 충분하고 그게 맞는듯 하다.

추가로 처음 이 문제를 접했을 당시 컴파일 옵션에 따라 이런식의 문제가 생길 수도 있다고 들었다. 해당 옵션은 지금껏 아무 생각 없이 써오던 '-O[n]' 옵션이다.
-O는 옵티마이저에서 따온듯하고 뒤의 숫자는 레벨을 뜻한다. 0~3까지 있는 줄 알았는데 자료를 찾아보니 더 많은 옵션이 있더라...
해당 옵션에 대해서는 나중에 더 자세히 봐야겠다. 일단은 링크만 해놓기로 하자.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

이전 포스트로 '명령 인자 처리에 대한 고민...'이란 글을 썼었다.
명령인자를 처리하는데 있어 가능한 정확하고 편하게 쓰게 하기 위해서 파서를 도입해야 하는 생각까지 했었는데...
역시 선배님들은 위대하시다...또는 내가 조금만 검색해봤어도 알아내지 않았을까 싶다.

위의 고민거리를 한방에 날려줄 함수 이름은 getopt와 getopt_long이다.
이 함수를 알고 제대로 이해해서 적용해보니 40라인에 육박했던 것이 60라인으로 늘어났다!?
하지만 getopt_long에서 책임주체가 되어 처리를 해주니 난 각 분기에 따른 설정만 해주면 된다. 코드를 보기 훨씬 쉬워졌다.
라인수는 기존 40라인에서 처리 못하고 있던 예외를 getopt에서는 처리해 주기 때문에 비교가 안될 것으로 보인다.
여튼 보기 좋다. 아래는 내가 적용해본 코드의 일부이다. 변수 선언은 굳이 기재 안해도 될 것 같음.

do {
    opt = getopt_long(argc, argv, sOpt, lOpt, NULL);
    switch(opt)
    {
        case 'u':
        case 'U':
            sUser = strdup(optarg);
            break;

        case 'd':
        case 'D':
            sMode = 1;
            break;

        case 'f':
        case 'F':
            sForce = 1;
            break;

        case 'h':
        case 'H':
            prtUsage(stdout);
            exit(0);
            break;

        case '?':
            prtUsage(stderr);
            exit(1);
            break;

        case -1:
            break;

        default:
            abort();
    }
} while (opt != -1);

아래의 내용은 http://blog.naver.com/pjfile/40012816089에서 가져왔다. 해당 블로그에 예제와 함께 더 자세히 나와있음.

생전 안하던 개발을 하려다 보니 실력도 없는 주제에 효율과 성능에 집착한다.
물론 지금 내가 몸담고 있는 회사의 주 사업 분야는 성능이 관건이긴 하지만, 대체로 몇 나노초가 차이난다고 해서 크게 달라질 건 없다. 그러나 이또한 특정 상황에서는 불과 1나노초라 할지라도 1초에 수십 수백번 호출이 되고 더 많이 호출된다고 가정하면 쌓이고 쌓여 결국 지연의 요소가 될 수도 있을 것이다.

각설하고 코딩을 하면서 성능 관련하여 고민하게 하는 요소인 부분이 있다.
예를 들면 아래와 같다.

1. if문을 두번 쓰는 것과 if ~ else if문을 쓰는 것
2. sizeof(var)를 쓰는 것과 직접 숫자로 기입하는 것
3. 변수마다 memset을 다 해주는 것
4. 두번 이상 반복되는 행위를 함수로 구현하여 수행하는 것과 분기마다 수행하는 것

이 외에도 여러가지가 있지만...지금 생각나는건 여기까지.

이 중에 오늘 알게 된 사실은 두번째 항목의 sizeof(val)을 사용하는 것과 직접 숫자를 기입하는 것에 관해서이다.
이제까지의 생각으로는 어찌되었든 프로그램이 수행되면서 sizeof라는 행위를 하게 되니 숫자를 기입하는 것보다는 느릴 것이다 라고 생각했는데, sizeof의 값은 컴파일 시에 결정이 되어 실제 구동 시에는 영향이 없다고 한다.
관련 자료는 더 찾아봐야하겠지만 이처럼 컴파일 시에 해주는 것도 있다는걸 알게된것이 새로웠다.

얼마전까지 코어 라이브러리 개발하시는 것을 가지고 공부하다가 지금은 유틸리티쪽으로 분야가 바뀌었다.
이번 도구 응용프로그램 분야 작업의 핵심은 파서구문 분석기(이하 파서, parser)라고 해도 무방할 정도로 파서의 비중이 높다. 당 블로그 카테고리에서 파서 제작 프로그램인 flex와 bison에 대한 분류를 새로 추가할 정도로 비중이 높다고 생각한다.
하지만 현재 파서 제작부분은 잠시 미뤄두고(혼자 진척이 거의 없고 봐주실 분이 너무 바쁘신 관계로) 다른 부분을 보고 있다.

현재 내가 생각하는 내 방향은 전반적으로 기존 프로그램을 이해하고 이번 공동 작업의 취지에 맞게 수정하며 추가로 가능하다면 내 코딩 스타일 혹은 내가 생각하는 처리 로직이 들어 갈 수 있게하도록 하는 것이기에 처음부터 쭉 읽어보고 옮겨쓰고 있는 중이다.
그 중에 이번 포스팅에서 거론할 부분은 제목과 같이 명령 인자 처리에 대한 고민이다. 유틸리리 툴 분야이다 보니 실행 시 프로그램명과 함께 인자를 주곤 한다. 인자 없이 도는 프로그램도 있지만 현재 대부분의 응용프로그램들이 인자를 줄 수 있게 되어있다.

고민의 요는 다음과 같다.

* 인자에 대한 처리에 있어 오류가 있어서는 안된다.
* 가능하다면 효율적이고 빠르게 처리하면 좋다.

편하게 짠다면 각각의 인자를 모두 조건문을 돌려 분기를 태우면 되는데 난 여기서 좀 더 구멍이 없는 로직을 태우고 싶은게다.
(솔직히 어떠한 예외도 없는 프로그램을 짜기란 쉽지 않다고 생각한다. 가능하면 그 예외를 미리 사전에 차단해 두는 것이라고 생각한다.)
각각의 인자를 처리하는데 있어 아래 사항을 

* 옵션간에 종속 혹은 연관 관계가 있을 경우 고려해 준다.
* 인자가 옵션명인지 옵션에 주어지는 값인지 판단해 주어야 한다.
* 옵션명은 대소문자에 관계 없이 처리해 준다.

이렇게 저렇게 짜보고는 있는데 갈수록 코드가 길어지고 지저분해 지는 것 같다. 그러다 문득 명령 인자를 처리하는데 있어서도 파서가 있다면 좀 더 완벽하지 않을까 하는 생각이 들어 포스팅을 하는 것이다.
결국엔 모두다 파서인가...

제목처럼 거창할 건 없지만 nm이란 명령을 사용하면 라이브러리의 내용을 볼 수 있다.
위키 백과에서는 아래와 같이 설명하고 있다.

내가 현재 사용하는 리눅스에서의 help 페이지이다.