17 개발환경 구축

17.1 필요한 것은 셋뿐이다

개발환경이라는 말이 거창하지만, C 프로그래밍에 필요한 것은 셋뿐이다.

• 컴파일러 — 16장의 네 주자 일체. 이 책은 gcc와 clang 두 계열을 기준으로 한다(둘 다 무료이고 모든 주요 플랫폼에 있다).
• 텍스트 편집기 — 소스 코드는 그냥 텍스트 파일이므로(9장), 글자를 적을 수 있는 도구면 무엇이든 된다. 어떤 편집기를 쓰는가는 취향의 영역이라 이 책은 정하지 않는다.
• 터미널 — 명령을 적어 넣는 창. 모든 운영체제에 기본으로 있다.

일과의 모양도 단순하다 — 편집하고, 컴파일하고, 실행한다. 이 세 박자 의 반복이 프로그래밍의 기본 사이클이고, 이 책의 모든 예제가 이 사이클 위에서 돈다(물론 독자는 지면으로 읽기만 해도 된다 — 1장의 약속대로, 이 장의 설치조차 시연이지 숙제가 아니다).

> winget install LLVM.LLVM

> clang hello.c -o hello.exe
> .\hello.exe
안녕, 세상!

$ pacman -S mingw-w64-ucrt-x86_64-gcc
$ gcc --version

17.2 설치가 부담이면 — 웹에서 바로 해 보기

앞 절의 셋을 갖추는 것이 정석이지만, 지금 당장 한 줄 돌려 보고 싶을 때는 브라우저만으로도 된다. 설치 없이 컴파일하고 실행해 주는 자리가 여럿 있고, 그중 몇은 이 책이 지면으로만 보여 준 것 — 최적화된 기계어, 포인터가 가리키는 자리 — 을 눈으로 보여 준다.

그림 17.1 — 소스 한 줄이 기계어 몇 줄이 되는지 나란히 보여 주는 화면 얼개.

17.2.1 학습용 옵션 — 웹에서도 그대로

어느 도구를 쓰든 옵션 칸을 비워 두지 않는 것이 요령이다. 다음 절에서 볼 경고 옵션(warning option)이 여기서도 그대로 통한다.

-std=c23 -Wall -Wextra -Werror -g -O0
-fsanitize=address,undefined        ← 지원하는 사이트에서만

• Compiler Explorer 는 컴파일러 이름 옆의 Compiler options 칸에 그대로 적는다.
• OnlineGDB 는 설정(톱니바퀴)의 Extra Compiler Flags 칸에 적는다.
• 사이트가 낡은 컴파일러를 기본값으로 주는 일이 흔하다. -std=c23이 거부되면 그 컴파일러가 오래된 것이니 목록에서 새 판을 고른다(-std=c2x가 통하는 중간 세대도 있다).

그림 17.2 — 값은 상자로, 포인터는 화살표로 — 시각화 도구가 그려 주는 그림.

기억 시각화는 특히 제7부(포인터와 기억)를 읽을 때 값이 크다. 이 책이 그림과 말로 설명한 「가리킨다」를, 자기가 적은 코드에서 직접 움직여 볼 수 있기 때문이다.

연습 문제를 주는 곳, 무료로 읽을 수 있는 자료, 그리고 오래된 자료를 가려내는 요령까지 부록 D에 모아 두었다. 이 책이 연습을 두지 않았으므로(머리말), 손으로 익히는 일은 그 부록의 자리에서 이어 가면 된다.

17.3 경고 — 공짜 검토를 켜 두어라

설치 직후에 들일 습관이 하나 있다. 컴파일러에게 경고를 넉넉히 켜 달라고 부탁하는 것이다:

$ cc -Wall -Wextra hello.c -o hello

-Wall -Wextra는 “수상한 구석을 최대한 알려 달라”는 뜻이다(이름과 달리 -Wall이 전부는 아니라서 관행상 둘을 함께 쓴다). 경고는 오류가 아니라 컴파일러의 무료 코드 검토다 — 계약(표준) 위반까지는 아니어도 사고 나기 좋은 무늬를 짚어 준다. 이 책의 모든 예제는 이 두 선택지를 켠 채, 경고 0개로 검증된다.

17.4 한글이 깨질 때 — 인코딩의 사슬

여기서 한국어권 독자가 거의 반드시 겪는 문제를 미리 짚어 둔다. 이 책의 예제가 출력 문자열을 대부분 영어로 쓰는 것도 이 사정 때문이다 — 한글을 찍는 순간, 프로그램 하나가 아니라 네 겹의 인코딩 설정이 전부 맞아야 글자가 제대로 나온다.

사슬의 네 고리는 이렇다.

• ① 소스 파일의 인코딩 — 소스는 결국 바이트 열이다(9장). 편집기가 UTF-8로 저장했는지, 아니면 옛 한국어 윈도우의 기본이던 CP949(EUC-KR 계열)로 저장했는지에 따라 같은 “안녕”이 다른 바이트가 된다.
• ② 컴파일러가 읽는 인코딩 — 컴파일러는 소스가 어떤 인코딩인지 추측하거나 기본값을 가정한다. 소스는 UTF-8인데 컴파일러가 CP949로 읽으면, 문자열 리터럴의 바이트가 그 자리에서 어그러진다.
• ③ 실행 문자 집합 — 컴파일러가 실행 파일에 심는 바이트가 무엇인가 (9장의 5단계, 57장의 번역 단계에서 본 그 변환이다).
• ④ 터미널이 해석하는 인코딩 — 프로그램이 뱉은 바이트를 창이 어떤 표로 읽는가. 여기가 어긋나면 앞의 셋이 완벽해도 화면에는 깨진 글자가 뜬다.

네 고리 중 하나만 어긋나도 증상은 똑같이 “글자가 깨진다”로 나타나므로, 초보자가 원인을 짚기가 유난히 어렵다. 진단의 요령은 어느 고리에서 깨졌는지 좁히는 것이다 — 소스를 16진으로 열어 보면(①②를 가름), 파일로 출력을 돌려 보면(④를 가름) 범인이 드러난다.

17.4.1 ②와 ③을 컴파일러에 못박는 법

9장에서 본 대로 C는 소스 문자 집합과 실행 문자 집합을 다른 것으로 취급하고, 둘 다 구현이 정한다. 그 「구현이 정하는 것」을 사람이 명시하는 옵션이 있다.

기본값을 알아 두면 사고가 줄어든다. GCC·Clang 은 양쪽 다 UTF-8이 기본이고, MSVC 는 현재 시스템 코드 페이지를 기본으로 삼는다(한국어 Windows 라면 CP949). /utf-8 한 줄이 Windows 쪽 사고의 절반을 없애는 이유가 이것이다.

/* 리터럴이 실제로 어떤 바이트·값이 되는가 — 층을 갈라서 본다.
   같은 소스라도 컴파일 옵션에 따라 첫 줄이 달라진다(본문의 실측 표). */
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <uchar.h>

static void dump(const char *tag, const char *p, size_t n)
{
    printf("  %-28s", tag);
    for (size_t i = 0; i < n; i++) printf(" %02X", (unsigned char)p[i]);
    puts("");
}

int main(void)
{
    const char    *plain = "가";      /* 리터럴 인코딩 — 구현이 정한다 */
    const char8_t *utf8  = u8"가";    /* 언제나 UTF-8 — 표준이 못박는다 */

    puts("[bytes of a string literal]");
    dump("\"가\"   (literal encoding)", plain, strlen(plain));
    dump("u8\"가\" (always UTF-8)", (const char *)utf8, strlen((const char *)utf8));

    puts("\n[code units of wide character literals]");
    printf("  u\"가\"[0] = U+%04X   (char16_t, UTF-16)\n",  (unsigned)u"가"[0]);
    printf("  U\"가\"[0] = U+%04X   (char32_t, UTF-32)\n",  (unsigned)U"가"[0]);
    printf("  L\"가\"[0] = U+%04X   (wchar_t, %zu bytes)\n",
           (unsigned)L"가"[0], sizeof(wchar_t));

    puts("\n[what the implementation claims to guarantee]");
#ifdef __STDC_ISO_10646__
    printf("  __STDC_ISO_10646__ = %ldL  -> wchar_t is Unicode\n",
           (long)__STDC_ISO_10646__);
#else
    puts("  __STDC_ISO_10646__ not defined -> wchar_t encoding is implementation-defined");
#endif
#ifdef __STDC_UTF_16__
    printf("  __STDC_UTF_16__    = %d      -> char16_t is UTF-16\n", __STDC_UTF_16__);
#endif
#ifdef __STDC_UTF_32__
    printf("  __STDC_UTF_32__    = %d      -> char32_t is UTF-32\n", __STDC_UTF_32__);
#endif

    puts("\n[the basic character set does not move]");
    printf("  'A' = %d, '0' = %d, sizeof \"A\" = %zu\n", 'A', '0', sizeof "A");
    return 0;
}

[bytes of a string literal]
  "가"   (literal encoding)   EA B0 80
  u8"가" (always UTF-8)       EA B0 80

[code units of wide character literals]
  u"가"[0] = U+AC00   (char16_t, UTF-16)
  U"가"[0] = U+AC00   (char32_t, UTF-32)
  L"가"[0] = U+AC00   (wchar_t, 4 bytes)

[what the implementation claims to guarantee]
  __STDC_ISO_10646__ = 201706L  -> wchar_t is Unicode
  __STDC_UTF_16__    = 1      -> char16_t is UTF-16
  __STDC_UTF_32__    = 1      -> char32_t is UTF-32

[the basic character set does not move]
  'A' = 65, '0' = 48, sizeof "A" = 2

시연은 기본 설정에서 돌린 결과다. 같은 소스를 옵션만 바꿔 다시 빌드하면 첫 줄이 달라진다 — 실측하면 이렇다.

두 가지를 읽어 낸다.

첫째, 같은 소스 파일이 다른 프로그램이 된다. 셋째 줄과 넷째 줄은 바이트가 똑같은 파일인데 결과가 다르다. 컴파일러에게 「이 파일은 EUC-KR 이다」라고 말해 주었느냐가 갈랐다.

둘째, 틀리게 말해도 대개 오류가 나지 않는다. 넷째 줄에서 컴파일러는 UTF-8 이라 믿고 읽었지만 아무 말 없이 통과시켰고, 바이트를 그대로 실행 파일에 실었다. 우연히 화면이 멀쩡해 보일 수도 있다 — 터미널이 CP949 라면. 네 고리가 다 어긋난 채로 결과만 맞아 보이는 상태가 가장 고약한데, 기계나 사람이 하나만 바뀌면 그때 깨진다.

17.5 디버거 — 멈춰 세워 들여다보기

프로그램이 틀린 답을 낼 때 가장 먼저 하는 일은 대개 printf를 심는 것이다. 나쁜 방법이 아니다 — 어디서나 되고, 준비가 필요 없다. 다만 찍을 자리를 미리 알아야 하고, 한 번 찍을 때마다 다시 컴파일해야 하며, 찍히는 것은 그 순간 그 변수뿐이다.

디버거(debugger)는 그 제약을 걷어낸다. 프로그램을 원하는 지점에서 멈춰 세우고, 그 순간의 모든 변수를 들여다보고, 한 줄씩 걸어 보고, 어떻게 여기까지 왔는지 호출의 사슬을 되짚는다. 표준 도구는 GNU의 gdb와 LLVM의 lldb이고, 명령 이름만 다를 뿐 하는 일은 같다.

예제로 쓸 프로그램은 이렇다. 합이 150이어야 하는데 100이 나온다.

#include <stdio.h>

static int sum_all(const int *a, int n) {
    int s = 0;
    for (int i = 0; i < n - 1; i++)   /* bug: stops one short */
        s += a[i];
    return s;
}

int main(void) {
    int data[5] = {10, 20, 30, 40, 50};
    printf("sum = %d (should be 150)\n", sum_all(data, 5));
    return 0;
}

sum = 100 (should be 150)

디버거로 붙잡으면 이렇게 보인다(gdb 17.2로 실제 실행한 것이다).

$ gcc -std=c23 -g -O0 bug.c -o bug
$ gdb -q ./bug
(gdb) break sum_all
Breakpoint 1 at 0x1154: file bug.c, line 4.
(gdb) run
Breakpoint 1, sum_all (a=0x7fff5302c8a0, n=5) at bug.c:4
4     int s = 0;
(gdb) print n
$1 = 5
(gdb) next
5     for (int i = 0; i < n - 1; i++)   /* bug: stops one short */
(gdb) next
6         s += a[i];
(gdb) print a[4]
$3 = 50
(gdb) finish
Run till exit from sum_all (a=..., n=5) at bug.c:4
Value returned is $4 = 100

n은 5로 제대로 들어왔고, 배열의 마지막 칸 a[4]에는 50이 멀쩡히 있는데 반환값은 100이다. 재료는 옳고 계산이 틀렸다는 뜻이므로 남은 곳은 루프의 경계뿐이다 — i < n - 1. 이 좁혀 가는 과정 자체가 디버거의 쓸모다.

17.6 디버그 빌드의 옵션 — -g와 -O0은 다른 스위치다

디버거가 변수 이름과 줄 번호를 알려면 컴파일러가 그 정보를 실행 파일에 넣어 두어야 한다. 그것이 -g다.

• -g — 디버그 정보(debug info)를 넣는다. 변수 이름, 타입, 줄 번호, 함수의 경계가 실행 파일 안에 함께 실린다.
• -O0 — 최적화를 끈다. 소스의 문장과 기계 명령이 거의 일대일로 대응 하므로, 한 줄씩 걷기와 변수 보기가 정확하게 동작한다.
• -Og — “디버깅하기 좋을 만큼만” 최적화한다. -O0보다 빠르면서 -O2보다 훨씬 잘 보인다. 디버깅용 기본값으로 좋다.
• -g3 — 매크로 정의까지 넣는다. print MAX_LEN 같은 것이 된다.

- -fno-omit-frame-pointer — 호출 사슬을 되짚는 실마리를 남긴다. 프로파일러와 크래시 보고에도 도움이 된다.

assert(51장)와 관련한 스위치도 하나 있다. -DNDEBUG를 주면 모든 assert가 통째로 사라진다 — 릴리스 빌드가 대개 그렇게 만들어진다. 검사를 지운다는 것은 디버그 빌드에서 걸리던 것이 릴리스에서는 그냥 지나간다는 뜻이므로, 사라져서는 안 되는 검사는 assert가 아니라 보통 if로 써야 한다.

17.7 디버거의 맹점 — 최적화된 빌드

문제는 릴리스 빌드다. 앞의 같은 프로그램을 -O2 -g로 만들어 붙잡으면 이렇게 된다(역시 실제 캡처다).

$ gcc -std=c23 -g -O2 bug.c -o bug
$ gdb -q ./bug
(gdb) break sum_all
Function "sum_all" not defined.
(gdb) break main
Breakpoint 1 at 0x1040: file bug.c, line 12.
(gdb) run
Breakpoint 1, main () at bug.c:12
12      printf("sum = %d (should be 150)\n", sum_all(data, 5));
(gdb) info locals
data = <optimized out>

찾던 함수가 없다. 컴파일러가 sum_all을 호출 자리에 펼쳐 넣고 (인라인), 상수 배열의 합을 아예 컴파일 시간에 계산해 버려서, 실행 파일 안에 그런 함수가 남아 있지 않기 때문이다. 배열 data도 마찬가지로 “최적화되어 사라졌다”. 13장에서 배운 편집자의 권리가, 여기서는 관찰자의 시야를 가리는 형태로 나타난 것이다.

최적화 빌드에서 흔히 만나는 맹점을 모으면 이렇다.

• <optimized out> — 변수가 레지스터에만 있거나 아예 없어져 값을 볼 수 없다(11장의 레지스터가 여기서 되돌아온다).
• 줄 번호가 튄다 — 한 줄씩 걸으면 12 → 15 → 12처럼 오간다. 컴파일러가 명령을 재배열했기 때문이고, 디버거는 거짓말을 하는 것이 아니라 뒤섞인 실제 순서를 보여 주는 것이다.
• 호출 사슬이 짧다 — 인라인된 함수와 꼬리 호출(tail call)은 스택에 프레임을 남기지 않는다.

- 중단점이 걸리지 않는다 — 지워진 코드에는 멈출 자리가 없다.

17.8 디버그에선 되는데 릴리스에서만 틀린다

가장 곤혹스러운 상황이고, 원인의 대부분은 하나로 모인다 — 프로그램은 이미 깨져 있었고, 디버그 빌드가 우연히 그것을 가려 주고 있었다. 최적화가 멀쩡한 코드를 망가뜨린 것이 아니라, 계약 밖의 코드(13장·52장)가 전제로 쓰이면서 비로소 증상이 드러난 것이다. 흔한 뿌리는 다음과 같다.

• 초기화하지 않은 지역 변수 — -O0에서는 스택의 그 자리가 마침 0이라 잘 돌다가, 배치가 바뀌면 쓰레기 값이 들어온다.
• 경계를 넘는 쓰기 — 넘어간 자리에 무엇이 놓였느냐가 빌드마다 다르다. 디버그 빌드에서는 여유 공간을 덮고 지나가던 것이, 릴리스에서는 하필 중요한 값을 덮는다.
• 계약 밖을 전제로 삼는 최적화 — 부호 있는 오버플로는 없다(7장), 엄격한 앨리어싱(13장)은 지켜진다, 널을 역참조한 뒤라면 널일 리 없다 — 이런 전제는 -O2에서만 실제 코드 변형으로 나타난다.
• volatile을 빠뜨린 폴링 루프 — 13장에서 본 그대로, -O0에서는 매번 읽던 것이 -O2에서 한 번만 읽히고 굳는다.
• 사라진 assert — -DNDEBUG로 검사가 통째로 빠지면서 잘못된 입력이 그대로 흘러 들어간다.
• 타이밍이 바뀌며 드러나는 경쟁 — 여러 갈래로 도는 프로그램(12장)에서 빨라진 코드가 순서를 바꾸어 놓는다. 디버거를 붙이면 느려져서 증상이 사라지는, 이른바 하이젠버그(Heisenbug)의 전형이다.
• 실수 계산의 미세한 차이 — -ffast-math류의 선택지는 결합 법칙을 가정해 순서를 바꾸므로 마지막 자리가 달라질 수 있다(8장).

17.9 디버거를 믿기 어려울 때의 도구들

디버거를 못 쓰거나 믿기 어려운 자리는 실제로 있다 — 최적화 빌드에서만 재현되는 버그, 붙이는 순간 사라지는 타이밍 버그, 디버거를 띄울 수 없는 운영 환경, 그리고 화면도 키보드도 없는 임베디드 보드. 그럴 때의 순서는 대략 이렇다.

1. -Og -g로 다시 세워 본다. 최적화를 완전히 끄지 않으면서 시야를 되찾는 첫 시도다. 여기서 증상이 남아 있다면 디버거가 다시 쓸 만해진다.
2. 새니타이저를 켠다. 다음 절의 도구들이다. 이들은 사고를 일어나는 순간에 잡으므로, 최적화 빌드에서만 나는 버그의 원인을 대개 여기서 찾는다. 릴리스와 같은 -O2에 얹어 쓸 수 있다는 점이 중요하다.
3. 가설을 플래그로 검증한다. -fno-strict-aliasing을 켜서 증상이 사라지면 원인이 앨리어싱 쪽임을 알 수 있다. 다만 이것은 진단이지 치료가 아니다 — 원인을 확인했으면 코드를 고친다.
4. 경고와 정적 분석을 최대로 올린다. -Wall -Wextra에 더해 -fanalyzer(GCC)나 clang --analyze는 실행 없이 잡아낸다.
5. 로그와 코어 덤프를 남긴다. 운영 환경에서는 이것이 유일한 창이다. 릴리스 빌드에 -g를 넣어 두었다면(앞의 오개념 상자) 사후에 그 덤프를 디버거로 열어 사고 지점을 소스 줄로 되짚을 수 있다.
6. 이분 탐색으로 좁힌다. 최적화 단계를 낮춰 가며(-O2 → -O1 → -O0) 어디서 갈리는지 보고, 버전 관리의 이력을 반으로 갈라 가며 언제 들어온 버그인지 찾는다(96장의 git bisect).
7. 최소 재현을 만든다. 문제를 재현하는 가장 작은 프로그램으로 줄이면 원인이 저절로 드러나는 일이 많고, 남에게 물어볼 수 있는 형태가 된다.

17.10 새니타이저 — 실행 중에 치는 그물

현대 C 개발환경의 필수 장비가 하나 더 있다. 컴파일 때가 아니라 실행 중에 사고를 잡는 도구, 새니타이저(sanitizer)다.

원리는 이렇다 — 컴파일할 때 특별한 선택지를 주면, 컴파일러가 프로그램 곳곳에 감시 코드를 심어 준다. 그 프로그램을 실행하면 감시 코드가 메모리 접근과 연산을 지켜보다가, 잘못이 일어나는 순간 현장을 짚으며 프로그램을 세운다. 대표 선수는 셋이다.

• ASan(AddressSanitizer) — 메모리 사고 담당. 경계를 넘는 접근, 해제 한 기억을 다시 만지기 같은, 제7부에서 만날 위험들을 현장에서 잡는다.
• UBSan(UndefinedBehaviorSanitizer) — 계약 위반 담당. 부호 있는 오버플로(7장), 폭 이상 시프트(7장) 같은 정의되지 않은 동작이 실행 중에 실제로 일어나면 그 자리에서 알린다. 52장의 주역이다.
• TSan(ThreadSanitizer) — 경쟁 사고 담당. 여러 코어(12장)가 같은 데이터를 다투는 문제를 잡는다. 이 책의 범위 밖이지만 이름은 알아 둔다.

쓰는 법은 컴파일 선택지 하나다:

$ cc -fsanitize=address,undefined -g hello.c -o hello
$ ./hello

(-g는 “사고 지점을 소스 몇 번째 줄인지로 알려 달라”는 부가 정보 선택지다.) 이렇게 빌드한 프로그램은 조금 느려지는 대신, 사고를 조용히 지나치지 않는다 — 7장에서 본 “오버플로는 조용하다”에 대한 현대의 응답이 바로 이 도구들이다. 이 책의 뒷부분(제7부, 제9부)에서 위험한 코드를 다룰 때, 새니타이저가 사고를 잡아내는 장면을 지면에서 여러 번 보게 된다.

17.11 제3부를 닫으며

첫 프로그램을 읽었고(15장), 그것이 실행 파일이 되는 릴레이를 구경했으며(16장), 그 릴레이를 내 책상에서 돌릴 도구와 그물까지 갖췄다(17장). 이제 준비는 끝났다.

다음 두 장은 이 부의 마무리이자 길잡이다. 우리가 방금 깐 gcc·clang 말고 세상에 어떤 C 컴파일러들이 현역으로 도는지(18장), 그리고 임베디드 개발자들이 make 와 git 곁에 무엇을 더 들고 일하는지(97장)를 훑는다. 지금 전부 설치할 필요는 없다 — 언젠가 그 이름들을 만났을 때 “무엇의 이름인지” 알아보는 것이 목적이다.

그다음 부부터 본격적인 언어 공부다 — 새 문법을 나열하는 것이 아니라, 15장의 헬로 월드 한 편을 완전히 읽어 내는 것이 제4부의 목표다.