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

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

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

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

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

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

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

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

고민의 요는 다음과 같다.

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

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

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

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

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

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

숙제 : unsigned char랑 char의 차이점. 꼭 구분해서 써야하는 예를 알려주세요.

위의 숙제를 받고 혼자 생각해본 바는...

이걸 구분해야 하는 이유가 있을 때는 어떤 때일까?
몇몇 블로그를 방문해 내요을 본 결과 대부분의 사람들은 1bit씩 나누어 통신을 하거나 무언가 비트 단위 작업을 할때 문제를 야기할 수 있다고 한다.
1bit씩 나누어 통신을 하는 경우에 발생하는 오류는 일반 환경에서는 발생하지 않지만 임베디드 환경에서는 발생 할 수 있다고 하는데 컴파일러 문제인지 잘 모르겠다;

또, 비트단위 작업의 경우 비트단위 연산자를 쓰면 오류가 발생한다는데 예제를 찾지 못했다. 대충 예상을 해보면 10진수로 표현했을 때 정수값이 같더라도 비트값은 틀리다는 것을 말하는 걸까 싶다.

뒤늦게 찾은 예제?

void main()
{
             unsigned char c=0x80;
             printf("%u\n",c);
             printf("%d\n",c);
}

void main()
{
             char c=0x80;
             printf("%u\n",c);
             printf("%d\n",c);
}

찾아본 마지막으로 오류 처리를 위한 결과 값을 if 문에 사용할 때이다.
보통 아래와 같이 작성을 하는데...이 때 unsigned char의 경우 조건문을 의도한대로 탈 수 없다는 것입니다.
if([함수 이름이나 함수 리턴값이 담긴 변수 이름] < 0) bla~ bla~
머...이건 별로 유념하지 않아도 될 것 같긴 합니다만...