52 정의되지 않은 동작

52.1 세 가지 회색지대 — UB, 미지정, 구현 정의

혼동되는 세 낱말을 먼저 갈라 둔다. 이 책이 여기까지 만난 사례들로 정리하면 이렇다.

앞의 둘은 “답이 여럿이지만 어쨌든 답은 있는” 세계다. UB만이 답 자체가 없는 세계다.

낱말을 다시 못박아 둔다. 위 표의 세 이름 — 구현 정의·미지정·정의되지 않은 동작 — 은 표준 문서에 그대로 적혀 있는 정식 용어다. 반면 이 장의 제목과 본문이 쓰는 「회색지대」는 12장에서 밝힌 대로 이 책이 편의상 붙인 이름이며 표준에는 없는 말이다. 남과 이야기할 때는 정식 낱말로 옮겨서 말해야 한다 — “이건 회색지대야”가 아니라 “이건 미지정이야” 또는 “이건 UB야”로.

52.2 왜 존재하는가

계약 밖을 남겨 둔 이유는 두 가지다. 첫째, 기계들이 서로 다르기 때문이다 — 7장의 폭 이상 시프트가 대표다. x86과 옛 ARM이 다르게 대응하는데 표준이 한쪽을 택하면 다른 쪽 기계는 매번 보정 코드를 넣어야 한다. 어느 편도 들지 않는 대신 “그 코드를 쓰지 말라”고 한 것이다. 둘째, 최적화의 전제를 얻기 위해서다 — 7장에서 본 대로 “부호 있는 정수는 넘치지 않는다”는 전제가 있어야 컴파일러가 루프를 분석하고 재배열할 수 있다(13장). C가 반세기 동안 속도의 언어로 남은 대가가 이 조항들이다.

52.3 “무엇이든 가능함”의 실제 얼굴

UB의 결과는 붕괴만이 아니다. 13장에서 본 무늬가 더 무섭다 — 컴파일러가 UB를 “일어날 리 없는 일”로 읽고 코드를 지워 버리는 것이다. 널 검사가 통째로 사라지거나(포인터를 이미 역참조한 뒤라면 “널일 리 없다”고 추론한다), 오버플로 검사가 사라지거나(부호 있는 넘침은 없다고 전제 하므로), 루프가 무한이 되거나 아예 없어진다. 그래서 UB의 대표적 증상은 “그 자리에서 죽는 것”이 아니라 엉뚱한 곳에서, 최적화 수준을 바꾸면 사라지는, 재현이 어려운 버그다.

52.4 계산이 시작되기도 전에 — 파일 모양의 UB

정의되지 않은 동작이라 하면 대개 넘침이나 널 역참조처럼 실행 중의 사고를 떠올린다. 그런데 표준의 목록(부속서 J.2)을 앞에서부터 읽으면 놀라운 것이 나온다 — 두 번째 항목이 파일의 마지막 글자에 대한 것이다.

즉 마지막 줄 끝에 개행이 없는 파일은, 문법이 아무리 완벽해도 계약 밖이다. 이 규정은 C89부터 있었고 C23(ISO/IEC 9899:2024)에도 그대로 남아 있다 — 부속서 J.2의 두 번째 항목이 그것이다. 참고로 C++는 2011년에 이 조항을 버렸다(없으면 개행을 붙인 것으로 친다고 정했다). 두 언어가 갈라선 드문 자리다.

왜 이런 것이 UB인가. 57장에서 본 번역 단계를 떠올리면 답이 나온다. 전처리기는 줄 단위로 일하고, 지시문 하나는 개행으로 끝나야 완성된다. 파일이 개행 없이 끝나면 마지막 줄이 미완성인 채로 남고, 그다음에 무슨 일이 벌어질지는 구현마다 다르다. 세 번째 줄의 “토막 난 토큰”도 같은 사정이다 — 따옴표가 닫히지 않은 문자열이나 */가 없는 주석으로 파일이 끝나면 전처리기는 다음 파일을 계속 읽어야 할지 판단할 근거가 없다.

오늘의 컴파일러는 대부분 조용히 개행을 붙여 준다(옛 GCC는 warning: no newline at end of file을 냈다). 그래서 실무에서 이 조항이 문제를 일으키는 자리는 컴파일러가 아니라 그 파일을 다루는 다른 도구들 이다.

52.5 그 밖의 기묘한 UB들

C23 기준으로 부속서 J.2는 정의되지 않은 동작을 218가지 나열한다. 대부분은 평생 만날 일이 없는 것들이지만, 그중에는 “이런 것까지?” 싶은 항목이 여럿 있다. 실행 중의 계산과는 무관한, 글자와 이름의 세계에서 벌어지는 것들을 골라 둔다.

앞의 셋은 앞 절에서 본 “파일 모양” 항목의 나머지 얼굴이다. 주석이나 문자열을 닫지 않은 채 파일이 끝나는 것도 같은 조항에 걸린다 — 어차피 컴파일이 안 될 것 같지만, 표준의 눈으로는 진단조차 요구되지 않는 자리다.

가운데 두 줄이 특히 실용적이다. 윈도우에서 #include "utils\str.h"라고 적는 것은 표준으로는 정의되지 않은 동작이다 — 실제로는 MSVC가 알아서 처리해 주지만, 이식하는 순간 문제가 된다. 표준이 보장하는 것은 /뿐이고, 다행히 윈도우 컴파일러들도 /를 받아들인다. 그래서 헤더 경로에는 언제나 /를 쓰라는 조언이 나온다.

short *p = &a[15]; 줄도 놀라는 자리다. 읽지도 쓰지도 않았는데 포인터를 만든 것만으로 계약 밖이다(배열의 끝 바로 다음 자리까지만 허용된다). “주소만 계산해 두고 안 쓰면 되겠지”가 통하지 않는 이유이고, 37장에서 포인터 산술에 경계를 그은 근거이기도 하다.

마지막 줄은 이 목록의 성격을 잘 보여 준다. 와이드 문자 변환 함수 하나가 “wctrans를 불렀을 때와 지금의 로케일이 같아야 한다”는 조건을 달고 있고, 어기면 UB다. 218가지 중 대부분이 이런 결이다 — 아주 좁고, 아주 구체적이고, 평생 만날 일이 없는.

void copy(int *dst, const int *src, size_t n) {
    memcpy(dst, src, n * sizeof *dst);   /* n == 0 이고 둘 다 널이면 UB */
}

52.6 피하는 법 — 규율, 도구, 그리고 부품

실무의 방어는 세 겹이다.

규율 — 이 책이 지나온 수칙들이 그 목록이다: 초기화하고 쓴다(23장), 경계를 지킨다(38장), 널을 확인한다(36장), 한 문장에서 한 변수는 한 번만 바꾼다(33장), 계약 밖의 지름길(포인터 캐스트, 표현 가정)을 쓰지 않는다(11·37장).

도구 — 17장에서 장만한 그물이다. 컴파일러 경고는 컴파일 시점에, UBSan·ASan은 실행 시점에 잡는다. C23이 들여온 검사 산술도 이 층의 도구다 — 넘침을 UB로 만들지 않고 값으로 알려 주는 함수들이다:

#include <stdckdint.h>
#include <stdio.h>

/* C23의 검사 산술: 넘치면 true를 돌려주고, 결과는 감아 돈 값이 담긴다. */
int main(void)
{
    int a = 2000000000;
    int b = 2000000000;
    int sum = 0;

    if (ckd_add(&sum, a, b)) {
        printf("%d + %d overflows int (we stayed inside the contract)\n", a, b);
    } else {
        printf("sum: %d\n", sum);
    }

    int small = 0;
    if (ckd_add(&small, 20, 22)) {
        printf("overflow\n");
    } else {
        printf("20 + 22 = %d\n", small);
    }
    return 0;
}

2000000000 + 2000000000 overflows int (we stayed inside the contract)
20 + 22 = 42

ckd_add는 “넘쳤는가”를 반환값으로 돌려준다 — 7장에서 배운 “부호 있는 넘침은 계약 밖”이라는 함정을, 51장에서 배운 “오류는 값이다”라는 규율로 다스리는 표준의 답이다.

부품 — 애초에 계약 위반이 어려운 API를 쓰는 것이다(43장의 proven이 그 층이다). 도구가 그물이라면 좋은 부품은 발판이라는 17장의 비유가 여기서 완성된다.

52.7 제9부를 닫으며

정밀의 부가 끝났다 — 근사를 다루는 법(50장), 실패를 다루는 법(51장), 그리고 계약 밖의 세계를 아는 법(52장). 세 장의 공통 주제는 하나다: C는 프로그래머에게 많은 것을 맡기는 언어이고, 맡겨진 것을 아는 사람이 안전한 코드를 쓴다.

마지막 부가 남았다. 지금까지의 프로그램은 파일 하나짜리였다 — 이제 여러 파일로 자라고(54장), 전처리와 번역의 층을 정면으로 보고(57장), 표준 라이브러리의 지형을 익히고(61장), proven을 정면으로 다루며(제12부), 모던 C의 관행으로 책을 닫는다(98장).

다음 부는 프로그램을 구성하는 이야기다. 그 첫 장은 지금까지 여섯 줄짜리 관례로만 써 온 자리 — main 자신이다. 세 가지 형태와, 돌려주는 값이 어디로 가는지를 본다.