정의되지 않은 동작

조금이라도 규모가 있는(nontrivial) C/C++ 코드는 거의 반드시 정의되지 않은 동작(Undefined Behavior, UB)을 품고 있다.
여기서 nontrivial이란 몇 줄짜리 예제를 넘어 실제 기능을 수행하는 코드, 즉 포인터, 정수 연산, 타입 캐스팅, 동시성 등이 얽히기 시작하는 코드를 말한다. 이 문서는 C/C++에서 UB가 왜 개인의 부주의만으로 설명되지 않는지를 정리한다.

30년 가까이 C/C++를 매일 써 온 전문가조차 UB를 끊임없이 만든다는 사실은, 이것이 개인 실력의 문제가 아니라 언어와 생태계가 부과하는 기본 비용에 가깝다는 것을 보여준다.[1]

조금 멋들어지게 문장을 써내려가면 아래처럼 정의 내릴 수 있다.

UB는 컴파일러가 악의적으로 최적화해서 터지는 문제가 아니다.
UB는 컴파일러가 "그런 상황은 발생하지 않는다"고 가정할 수 있게 만드는 권리다.

UB가 있는 코드는 컴파일러, ABI, 하드웨어, 런타임이 모두 "정상 C 코드라면 이런 일은 없다"는 전제 위에서 동작한다.
사람이 읽으면 의도가 명백해 보여도, 컴파일러 단계 사이나 모듈 사이에는 그 의도를 표현할 수단이 없을 수 있기 때문에 발생한다.
즉 컴퓨터와 사람의 의사 소통이 다르기때문이다.

0. UB와 비슷한 말들

C/C++ 표준 문서를 읽을 때는 비슷해 보이는 표현을 구분해야 한다. C계열 언어의 고질병이다.

C++ working draft도 undefined behavior를 "no requirements"로 다루며, 가능한 결과는 무시, 예측 불가능한 실행, 진단 후 종료 등 넓게 열려 있다고 설명한다.[7] cppreference도 C/C++ UB 예시로 범위 밖 메모리 접근, signed integer overflow, null pointer dereference, strict aliasing 위반 등을 든다.[6][8]

구분:

• implementation-defined는 문서화된 구현 선택이다. 위험은 남는다.

• unspecified는 몇 가지 가능한 선택 중 하나다.

• UB는 선택지가 정해져 있지 않다.

UB는 "랜덤한 결과가 나온다"보다 범위가 넓다고 볼 수 있다.
매번 이상하게 터진다는 뜻도 아니다.
평소에는 동작하다가, 컴파일러 버전이나 최적화 옵션을 바꾼 뒤 해당 경로가 불가능한 것으로 취급될 수 있다.

즉 예측할 수 없기때문에 '정의되지 않은 동작'인 것이다.

1. -O0는 UB를 정의된 동작으로 만들지 않는다

-O0(Optimization Level 0, 컴파일러의 최적화 끄기 옵션)를 준다고 해서 UB가 정의된 동작으로 바뀌지는 않는다. 흔히 개발자들은 "최적화를 완전히 끄면 컴파일러가 소스 코드를 있는 그대로 1:1 기계어로 번역할 테니, 예측할 수 없는 이상한 동작(UB)은 피할 수 있을 것"이라고 착각한다.[1]

문제는 모든 UB가 같은 방식으로 드러나지 않는다는 데 있다. 애초에 왜 정의 되지 않은 동작이겠는가.
일단 보통 크게 대 분류로 2개를 갈라보자

첫째, 하드웨어나 ABI와 직접 맞닿는 UB의 경우
정렬되지 않은 포인터 접근, 범위 밖 메모리 접근, 잘못된 함수 포인터 호출, 잘못된 object lifetime 접근 같은 경우는 최적화 수준과 무관하게 크래시, 트랩, 엉뚱한 메모리 접근으로 나타날 수 있다.
이 경우 -O0는 프로그램을 안전하게 만들지 않는다.
단지 컴파일러가 덜 공격적으로 재작성할 가능성이 높아질 뿐.

둘째, 컴파일러의 최적화 패스가 UB를 전제로 삼으면서 드러나는 경우. null check 제거, signed overflow를 이용한 조건식 단순화, dead code elimination, loop optimization 같은 사례가 여기에 속한다. 이런 변환은 보통 -O2, -O3, LTO, 특정 타깃 최적화에서 더 잘 보인다. -O0에서는 같은 코드가 겉보기에는 의도대로 실행될 수 있다. 그러나 그것은 코드가 정의된 동작이 되었다는 뜻이 아니라, 특정 빌드에서 아직 그 UB가 적극적으로 이용되지 않았다는 뜻에 가깝다.

이 과정을 “전화 게임(telephone)”에 비유할 수 있다. 소스 코드의 의도는 컴파일러 중간 표현(IR), 최적화 단계, ABI, 하드웨어 명령을 거치며 계속 변환된다. 지금 -O0 환경에서 우연히 의도대로 동작하더라도, 미래의 컴파일러 버전이나 다른 아키텍처에서 같은 결과가 나온다는 보장은 없다.

LLVM과 John Regehr의 고전적 정리도 이 관점과 연결되 있다. 컴파일러는 valid C/C++ program에서는 UB가 발생하지 않는다고 가정할 수 있고, 그 가정은 케이스 분석, dead code elimination, null check 제거, loop optimization에 직접 연결된다[3][4]

정확히 말하면, -O0에서도 UB는 UB다. 다만 UB를 이용한 공격적인 코드 제거와 재작성은 보통 최적화가 켜질 때 나타날뿐. 이 둘을 혼동하면 “그럼 -O0에서는 null check가 안 지워지잖아?”라는 말에 약해진다.

예를 들어서 다음 코드를 보자.

int *p = get_pointer();
int value = *p;          /* (1) 역참조 성공 = 이후 p는 non-null이라고 가정 가능 */
if (p == NULL) {         /* (2) "역참조가 성공했으니 p는 NULL일 수 없다" */
        return -1;       /* (3) 분기 전체가 dead code로 제거됨 */
}
return value;            /* value가 실제로 쓰이므로 (1)의 로드는 제거되지 않는다 */

사람이 읽으면 “포인터를 읽고, null이면 에러를 반환한다”고 생각할 수 있다. 그러나 p가 null이라면 (1)의 역참조 시점에서 이미 UB가 발생한다. 즉 이 코드는 null check가 있는 코드가 아니라, null check가 너무 늦게 나온 코드다.

최적화가 켜지면 상황은 더 강해진다. 컴파일러는 valid program에서는 (1)의 역참조가 성공했다고 볼 수 있고, 그 사실로부터 p가 null이 아니라고 추론할 수 있다. 그러면 뒤의 if (p == NULL) 분기는 dead code로 제거될 수 있다.

int *p = get_pointer(); 
int value = *p; 
return value;

이것은 컴파일러가 악의적으로 방어 코드를 없앤 것인가? 그건 아니다.
C/C++ 표준이 valid program에서는 null pointer dereference가 발생하지 않는다고 놓고 코드를 해석할 수 있게 만든 것이다. UB가 있는 경로에서는 “이상한 값이 나온다”보다 “그 경로를 불가능한 경로로 취급할 수 있다”가 더 정확한 모델이다.
LLVM 글의 null check 제거 사례가 이 형태이며, Linux 커널에서 실제 취약점으로 이어진 적도 있다. [4]

예를 들어 signed overflow가 UB라는 사실은 단순히 "값이 이상해질 수 있음"이 아니다.

int greater_after_increment(int x)
{
        return x + 1 > x;
}

사람은 x == INT_MAX일 때 overflow가 나서 이상해질 수 있다고 생각한다. C/C++의 signed overflow는 UB다. 컴파일러는 valid program에서는 x + 1이 overflow하지 않는다고 가정할 수 있고, 이 함수는 항상 true를 반환한다고 최적화될 수 있다.

최적화가 켜진 빌드에서는 이 함수가 다음처럼 단순화될 수 있다.

int greater_after_increment(int x)
{
        return 1;
}

-O0에서는 실제 덧셈과 비교가 그대로 남을 수 있다. 그러나 그것이 x == INT_MAX 입력을 정의된 동작으로 만든다는 뜻은 아니라는 뜻이다.
해당 입력에서 signed overflow가 발생하면 이미 표준의 보장이 존재하지 않는 다는 것이고, 단지 그 빌드에서는 컴파일러가 그 UB를 이용해 조건식을 접지 않았다는 것이다.

따라서 결론은 “UB는 최적화 옵션 때문에 생긴다”가 아니다. 또한 "-O0에서도 늘 같은 방식으로 생긴다"도 아니다.그게 하드웨어 트랩으로 나올지 우연히 굴러갈지 최적화 단계의 방어 코드 증발로 나올지는 빌드와 플랫폼이 정한다. 그리고 이게 더 악질이라고 생각하는게 진짜 내 컴퓨터에서는 잘 되기 때문이다. [4]

2. 주요 UB 사례

아래 사례들은 주로 자주 발생하는 메모리 안전성 3종 세트(double-free, use-after-free, 범위 초과)보다 훨씬 평범한 코드 주변에 숨어 있다.
전수 목록은 아니다.
전수 목록을 만들면 문서가 아니라 퇴마 의식이 될 것이다.

개인적인 메모: C 프로그래머는 심신의 안정을 위해 종교를 가지는 것이 좋다 생각한다.

2.1 정렬되지 않은 포인터 접근 (C23 6.3.2.3)

int foo(const int *p)
{
        return *p;
}

p가 int의 정렬 조건(대개 sizeof(int)의 배수 주소)을 만족하지 않으면 역참조는 UB이며 결과는 플랫폼마다 다르다.

• Linux Alpha: 일부 로드에서 커널이 트랩을 받아 의도한 동작을 소프트웨어로 에뮬레이션. 다른 로드에서는 SIGBUS로 크래시.

• SPARC: SIGBUS.

• x86/amd64: 대부분의 경우 문제없이 동작하고, atomic read처럼 보일 때도 있다. 캐시 일관성에 관대한 아키텍처이기 때문.

개인메모: "내 머신에서는 잘 도는데?"라는 말은 C 표준 앞에서 가장 무의미한 문장이다. x86에서 얌전히 돌아갔다고 한들, 그것은 표준이 당신의 코드를 보증한 것이 아니라 단지 그날의 하드웨어가 생리하지 않았을뿐이다. 컴퓨터는 언제나 생리하는 여성처럼 대하는 게 중요하다.

컴파일러는 정렬되지 않은 포인터를 위해 안전한 기계어를 생성해 줄 의무가 전혀 없다.
언제든 최적화를 핑계로 다른 로드 명령을 생성할 수 있으며, 그 순간 하드웨어가 베풀던 얄팍한 자비는 사라지고 프로그램은 즉시 크래시로 응답할 것이다.

원자성도 비슷하다.

정렬되지 않은 std::atomic<int>에 대한 store/load가 atomic이냐고 묻는 순간 이미 길을 잘못 들었다. 언어 표준 관점에서는 객체의 정렬 조건을 어긴 시점에서 UB이므로, 그 뒤의 하드웨어 원자성 논의는 “표준 C++ 코드의 의미”가 아니라 특정 구현과 CPU에서 우연히 어떤 일이 벌어질 수 있는가의 문제라고 볼 수 있다.

다만 x86/amd64 하드웨어 관점에서도 경계가 있다. Intel 문서 기준으로 P6 이후 프로세서는 캐시 가능한 메모리에서 하나의 캐시 라인 안에 완전히 들어가는 비정렬 16/32/64비트 접근을 원자적으로 수행한다고 설명한다. 그러나 접근 대상이 캐시 라인 경계나 페이지 경계를 가로지르는 순간 이 보장에서 벗어난다.[15]

따라서 “페이지 경계에 걸치면 atomicity가 깨질 수 있다”는 설명은 틀린 말은 아니지만, 더 정확히는 “캐시 라인 경계를 넘는 split access는 원자성이 보장되지 않으며, 페이지 경계는 그보다 더 극단적인 split/fault 사례”라고 쓰는 편이 맞다.

LOCK이 붙은 연산은 split lock으로 버스 락이나 강한 직렬화를 유발할 수 있지만, 그것 역시 성능과 구현 세부의 문제이지 misaligned std::atomic<T>를 표준적으로 안전하게 만들어 주는 것은 아니다.

또한 더 엄격하게는, 캐스팅 자체가 문제가 될수도 있다.

bool parse_packet(const uint8_t *bytes)
{
        const int *magic_intp = (const int *)bytes;   /* ✗ 여기서 이미 UB */
        int magic_raw = foo(magic_intp);              /* SPARC에서 크래시 가능 */
        int magic = ntohl(magic_raw);                 /* 이 줄 자체는 문제없음 */
        /* ... */
}

여기서 더 불편한 부분은 foo()의 역참조만 문제가 아니라는 점이다. 잘못 정렬된 객체 타입 포인터를 만드는 캐스팅 단계부터 이미 UB다
"읽기 전까지는 캐스팅만 해도 괜찮다"라는 안일한 생각이 여기서 문제를 일으킨다.

7 A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned59) for the referenced type, the behavior is undefined.

(C23 6.3.2.3p7: 변환 결과 포인터가 대상 타입에 맞게 정렬되지 않으면 그 변환 자체가 UB).

대부분의 C/C++ 프로그래머는 캐스팅 자체는 안전하고 그 포인터로 읽고 쓸 때(*p)서야 문제가 터진다고 생각하지만, 표준은 정렬 안 맞는 변환은 그 즉시 UB라고 못박는다. 메모리에 접근하기도 전에, 캐스팅하는 행위 그 자체로 이미 컴파일러가 사고치게 두는 것이다. 컴파일러가 int *의 하위 비트에 가비지 컬렉션이나 보안 태깅 같은 의미를 부여하는 것도 표준상 허용된다.

그런데 이 예제의 UB는 정렬 하나로 끝나지 않는다. 원래 객체가 uint8_t 배열인데 그것을 int lvalue로 읽는 행위는 strict aliasing(effective type) 규칙 위반이기도 하다(2.7 참고).
설령 bytes가 운 좋게 4바이트 정렬을 만족해서 정렬 UB를 피하더라도, int로 읽는 순간 aliasing UB가 따로 남는다. 패킷을 정수로 캐스팅해 파싱하는 이런 코드가 위험한 이유는 규칙 하나를 어겨서가 아니라, 정렬과 effective type을 한 줄에서 동시에 밟기 때문이다. 안전한 길은 memcpy로 바이트를 복사해서 들어오는 것이다.

2.2 isxdigit(char) 문제 (C23 7.4, 6.2.5)

bool bar(char ch)
{
        return isxdigit(ch);   /* ✗ char가 signed인 플랫폼에서 UB 가능 */
}

In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined

isxdigit 계열 함수는 unsigned char로 표현 가능한 값 또는 EOF를 받도록 정의된다. EOF는 int이며 unsigned char로 표현되지 않는 음수다. 따라서 인자 타입은 int다.

char가 signed인 플랫폼(구현 정의, 6.2.5)에서 0x80 이상의 바이트를 넘기면 음수 int로 변환되고, 다음과 같은 valid한 구현에서 엉뚱한 메모리를 읽게 된다.

int isxdigit(int c)
{
        if (c == EOF) {
                return false;
        }
        return some_array[c];   /* c가 음수면 배열 밖 읽기 */
}

이 메모리가 I/O mapped 영역이면 단순한 random 값/크래시로 끝나지 않을 수 있다.
임베디드 환경이라면 모터가 돌 수도 있다. isxdigit() 한 번 잘못 불렀는데 기계가 움직이면, 그날은 집에 가서 C 책을 베개 밑에 넣고 자도 된다.

방어 형태는 아래와 같다.

  /* 좋은 예시 */
bool bar(char ch)
{
        return isxdigit((unsigned char)ch) != 0;   /* ✓ */
}

2.3 float를 int로 변환 (C23 6.3.1.4)

int milliseconds(float seconds)
{
        int tmp = (int)(seconds * 1000.0);   /* ✗ 범위 초과 시 UB */
        return tmp + 1;                       /* ✗ signed overflow도 별도 UB */
}

If the value of the integral part cannot be represented by the integer type, the behavior is undefined.

유한한 부동소수 값을 정수형으로 변환할 때 정수부가 대상 타입으로 표현 불가능하면 UB다(6.3.1.4). 생략에 의해 NaN/Infinity 같은 비유한 값도 UB다.

어려운점은 안전하게 비교하는 일조차 간단하지 않다는 데 있다. INT_MAX를 float로 캐스팅하면 정확히 표현된다는 보장이 없어 비교가 부정확해질 수 있다.
방어코드는 아래와 같다.

int milliseconds(float seconds)
{
        const float ftmp = seconds * 1000.0f;

        if (!isfinite(ftmp)) {
                return 0;   /* 또는 다른 에러 보고 */
        }
        if ((float)(INT_MIN + 1000) > ftmp) {
                return 0;
        }
        if ((float)(INT_MAX - 1000) < ftmp) {
                return 0;
        }

        /* 이제 변환해도 안전 */
        const int tmp = (int)ftmp;
        if (INT_MAX == tmp) {
                return 0;
        }

        /* 이제 더해도 안전 */
        return tmp + 1;
}

"초를 밀리초로 바꾸려 했을 뿐인데" 이만큼이 필요하다.
오픈소스만 봐도 그냥 곱하고 캐스팅하는 코드가 널려 있다.

개인메모:이쯤 되면 C는 계산보다 사고치는 경계 확인을 먼저 가르치는 언어다.

2.4 주소 0과 널 포인터 (C23 6.3.2.3, 6.5.4.2)

C 표준의 NULL(정수 상수 0 또는 nullptr에서 변환된 null pointer constant)은 하드웨어 주소 0과 동일하다는 보장이 없다. 표준은 철저히 'C 추상 기계(Abstract Machine)' 위에서만 동작하기 때문이다. 보장되는 것은 "NULL을 0과 비교하면 같게 평가된다"는 사실뿐이며, 그 0이 플랫폼 고유의 NULL(예: 0xffff)로 변환된 결과일 수도 있다.

이러한 널 포인터를 역참조하는 행위는 명백한 UB다. C 표준 6.5.4.2는 이를 다음과 같이 규정한다.

"If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined."

표준은 포인터에 '유효하지 않은 값'이 들어있을 때 역참조(*)를 하면 UB가 발생한다고 선언하며, 해당 조항의 각주(101)를 통해 그 유효하지 않은 값의 첫 번째 예시로 널 포인터(null pointer)를 정확히 지목하고 있다.

이러한 언어적 특성 때문에 실제 현장에서는 자주 발생하는 함정이 2개 있다.

memset(&ptr, 0, sizeof(ptr));   /* ✗ ptr이 NULL이 된다는 보장 없음 */

구조체를 0으로 밀어 멤버 포인터가 모두 NULL이 된다고 가정할 수 없다.
대부분의 현대 플랫폼에서는 동작한다.
다만, 표준 차원의 보장은 아니다.

void (*func_ptr)() = NULL;
func_ptr();   /* ✗ null 역참조, 6.5.4.2의 UB 예시 */

null 포인터 역참조는 그 값이 무엇이든 UB다(6.5.4.2). 6.3.2.3은 NULL이 "임의의 객체나 함수"와 같지 않다고 명시하므로, 실제 주소 0에 객체나 벡터 테이블이 있더라도 표준 C 관점에서는 그 위치를 일반 객체처럼 다룰 수 없다.
"all zeroes 비트 패턴으로 call 명령을 내면 되지 않나"라는 생각도,
16비트 x86에서 0000:0000인지 CS:0000인지처럼 "all zeroes"의 정의 자체가 모호해지면서 무너지게 되어있다.

OS 커널/임베디드 쪽에서는 이게 농담이 아니다.

개인메모:일반 앱 개발자는 주소 0을 보통 버그로 만나지만, 커널과 임베디드 쪽 사람들은 주소 0을 동네 주민처럼 만난다. 가끔 동네 술집 들어가서 술 한잔 걸치기도 하겠지.

2.5 가변 인자와 타입 불일치

execl("/bin/sh", "sh", "-c", "date", NULL);   /* ✗ */
execl("/bin/sh", "sh", "-c", "date", 0);      /* ✗ */
execl("/bin/sh", "sh", "-c", "date", (char *)NULL);   /* ✓ */

가변 인자 종료 표식은 포인터 타입이어야 하는데, NULL 매크로가 정수 0으로 해석될 수 있어 캐스팅이 필요하다.

여기엔 ABI 레벨의 뉘앙스가 있다. NULL이 ((void *)0)로 정의된 구현(상당수 POSIX)에서는 execl(..., NULL)도 포인터를 넘기므로 실무상 동작한다. 진짜로 깨지는 경우는 NULL이 정수 0으로 정의되고 int가 32비트, 포인터가 64비트인 LP64 환경이다.
가변 인자에는 타입 정보가 없어 호출 측은 32비트 int를 넘기지만, execl은 내부에서 va_arg(ap, char *)로 64비트 포인터를 꺼낸다. 폭이 어긋나 상위 비트에 가비지가 섞이면 종료 표식이 NULL로 인식되지 않을 수 있다.
(char *)NULL로 캐스팅하면 정의에 무관하게 포인터 폭으로 전달된다.

uint64_t blah = 123;
printf("%ld\n", blah);   /* ✗ format과 인자 타입 불일치 = UB */

printf("%" PRIu64 "\n", blah);   /* ✓ */

uint64_t는 PRIu64 같은 매크로로 출력해야 한다. uid_t처럼 부호가 구현 정의인 타입은 uintmax_t로 캐스팅 후 PRIuMAX로 출력하는 식으로 우회한다.

2.6 0으로 나누기

0으로 나누기가 UB라는 사실은 다들 안다.
그런데 생각보다 자주 나온다. 분모가 신뢰할 수 없는 입력에서 오는 경우가 생각보다 많고, divide-by-zero는 공격 표면이 될 수 있다.

참고로 C23 표준은 "undefined"라는 단어를 283번 쓴다. 생략에 의해 정의되지 않는 것들은 여기 포함되지도 않는다.

개인메모:Undefined가 283번이면 그건 경고가 아니라 어쩌면 철학이라고 생각한다.

2.7 strict aliasing

C/C++에서는 어떤 객체를 아무 타입 포인터로나 읽을 수 없다. 서로 alias할 수 없는 타입이라고 판단되면 컴파일러는 두 포인터가 같은 메모리를 가리키지 않는다고 가정할 수 있다.

int f(int *i, float *f)
{
        *i = 1;
        *f = 0.0f;
        return *i;
}

i와 f가 실제로 같은 주소를 가리키도록 억지로 만들면, 사람이 보기에는 *f = 0.0f가 *i의 비트를 덮을 수 있다. strict aliasing 규칙상 int *와 float *는 일반적으로 같은 객체를 가리킨다고 볼 수 없다. 컴파일러는 return *i를 return 1로 볼 수 있다.

바이트 복사는 memcpy로 우회하는 편이 안전하다.

float read_float_from_bytes(const unsigned char bytes[sizeof(float)])
{
        float value;
        memcpy(&value, bytes, sizeof(value));
        return value;
}

char, unsigned char, std::byte 계열은 객체 표현을 읽는 특별한 통로로 다뤄진다. 임의 타입 포인터로 재해석하는 코드는 별도 규칙을 따라야 한다.

2.8 객체 수명과 placement new

C++에서는 메모리 주소가 있다고 해서 그 위치에 원하는 타입의 객체가 살아 있는 것은 아니다. 객체의 storage와 lifetime은 다르다.

alignas(std::string) unsigned char buffer[sizeof(std::string)];

auto *s = reinterpret_cast<std::string *>(buffer);
// *s를 여기서 사용하면 안 된다. 아직 std::string 객체가 시작되지 않았다.

객체를 실제로 만들려면 placement new 같은 수명 시작 작업이 필요하다.

auto *s = new (buffer) std::string("hello");
std::cout << *s << "\n";
s->~basic_string();

C++의 object lifetime 규칙은 allocator, arena, serialization, ECS, custom container를 만들 때 자주 문제가 된다. "메모리만 확보했다"와 "그 타입의 객체가 살아 있다"는 같은 말이 아니다.

2.9 data race

C++에서 data race는 UB다. 두 스레드가 같은 메모리에 접근하고, 하나 이상이 쓰기이며, 적절한 synchronization이 없으면 프로그램 전체가 정의되지 않는다.

int counter = 0;

void worker()
{
        counter++;   // 여러 스레드가 동시에 실행하면 data race
}

이럴 때는 원자 타입을 쓴다.

std::atomic<int> counter = 0;

void worker()
{
        counter.fetch_add(1, std::memory_order_relaxed);
}

data race가 UB인 이유는 단순히 값이 틀릴 수 있어서가 아니다. 컴파일러와 CPU가 메모리 접근을 재배치하고 레지스터에 값을 유지할 수 있기 때문이다. 동시성 data race는 단순한 값 오류가 아니라 언어 모델 밖의 상태에 가깝다.

2.10 shift UB

시프트도 흔한 UB 지점이다.

int x = 1 << 31;       /* int가 32비트라면 UB 가능 */
int y = 1 << -1;       /* UB */
int z = 1 << 32;       /* 32비트 int라면 UB */

시프트 개수가 음수이거나 타입 폭 이상이면 UB다. signed 타입에서 표현 불가능한 결과를 만드는 left shift도 문제가 된다. 비트 연산 코드는 uint32_t, uint64_t 같은 명시적 unsigned 타입으로 작성하고, shift count를 먼저 검증하는 편이 낫다.

단 signed left shift는 C++20에서 규정이 다르다

3. 보너스: integer promotion (UB는 아니지만 함정)

UB는 아니지만, integer promotion 규칙은 코드를 빠르게 훑으며 판단하기 어렵다. 이 규칙은 작은 타입으로 보이는 연산을 실제로는 int 연산으로 바꾼다.

unsigned char a = 0xff;
unsigned char b = 1;
unsigned char zero = 0;
bool overflowed = (a + b) == zero;
/* overflowed는 0(false). a, b가 int로 승격되어 0x100이 되므로 zero와 다름 */

unsigned char a = 0x80;
uint64_t b = a << 24;
/* b는 0x80000000(2147483648)이 아니라 0xffffffff80000000(18446744071562067968) */
/* 모든 변수가 unsigned여도 그렇다. a가 int로 승격된 뒤 시프트되어 부호 확장 */

모든 변수가 unsigned여도 promotion은 int에서 일어나고, 그 결과의 부호 확장이 최종 값을 바꾼다. 사람이 skim 속도로 promotion 규칙을 적용하는 것은 사실상 불가능하다.

엄밀히 말하면 위의 a << 24는 promotion 함정인 동시에 그 자체가 UB이기도 하다. int로 승격된 0x80을 24비트 시프트하면 결과가 2^31이 되어 signed int로 표현할 수 없고, 이런 signed left shift는 UB다.

이 지점에서 C와 C++의 최신 규정이 갈리는 것을 체크하였다.
C++20은 signed 정수를 2의 보수로 고정하면서 signed left shift를 modulo 연산으로 정의해, 이 시프트가 정의된 동작이 되었다.
반면 C23도 signed 정수 표현을 2의 보수로 못박았지만, signed left shift의 overflow는 여전히 UB로 남겨 두었다.
표현 방식이 정해졌다고 산술/시프트 overflow까지 정의되는 것은 아니다.
따라서 같은 0x80 << 24라도 C23에서는 UB, C++20 이상에서는 정의된 동작이다. 어느 쪽이든 비트 연산은 uint32_t, uint64_t 같은 명시적 unsigned 타입으로 작성하는 편이 안전하다.

4. 다른 언어들은 이 비용을 어떻게 처리하는가

C/C++의 UB는 "프로그래머가 멍청해서 생기는 실수"만으로 설명되지 않는다. 전문가도 30년간 계속 만든다면, 개인 실력보다 언어와 생태계의 기본 비용을 봐야한다고 생각한다.

다른 언어들은 이 비용을 주로 네 방향 중 하나로 처리한다.

4.1 Rust

타입 시스템과 borrow checker로 C/C++의 많은 UB 영역을 컴파일 타임에 차단한다. 배열 범위 초과는 UB가 아니라 panic이고, use-after-free/double-free/data race는 safe Rust에서 대부분 컴파일 단계에 막힌다.

let value = vec![1, 2, 3];
let x = value[10];   // UB가 아니라 panic

Rust에도 UB는 있지만 unsafe 블록으로 책임이 격리된다.

unsafe {
    let p = 1 as *const i32;
    let x = *p;   // UB 가능
}

unsafe 블록으로 격리 한다는 건.

C/C++는 평범한 길에도 지뢰가 섞여 있지만, Rust는 적어도 safe 영역에서는 다리 잘릴 각오하고 들어오라고 경고라도 해준다.
물론 unsafe 문을 열면 다시 본인이 책임져야 한다.

4.2 Zig

Zig는 C보다 더 명시적인 저수준 언어다. overflow, alignment, optional, error handling을 언어 차원에서 더 드러낸다. debug/safe 빌드에서는 integer overflow를 trap할 수 있고, release-fast에서는 성능을 위해 일부 체크가 빠진다. @intCast, @alignCast, @ptrCast처럼 위험한 변환도 코드에 드러난다. pointer, alignment, unsafe operation이 남아 있으므로 UB가 사라진 언어는 아니다. 그리고 솔직히 내가 잘 모르기도 한다.

4.3 Go

정의된 동작을 선호한다. 배열/slice 범위 초과와 nil 역참조는 보통 panic이고, GC가 있어 일반 코드에서는 use-after-free/double-free가 없다. unsafe 패키지로 C식 위험을 다시 열 수 있다.

arr := []int{1, 2, 3}
fmt.Println(arr[10])   // UB가 아니라 panic

4.4 Java / C#

대부분의 C식 UB를 런타임 예외로 바꾼다.

int[] arr = { 1, 2, 3 };
Console.WriteLine(arr[10]);   // IndexOutOfRangeException

int[] arr = {1, 2, 3};
System.out.println(arr[10]);   // ArrayIndexOutOfBoundsException

범위 초과는 예외, null 참조는 예외, 메모리 해제는 GC, 타입 불일치는 런타임/컴파일 타임 검사로 처리된다. C#은 unsafe 블록으로 포인터를 쓸 수 있지만 위험 영역이 문법적으로 표시된다.
Java도 Unsafe, JNI, Panama 경로가 있으나 일반 코드와 분리된다.

unsafe {
    int* p = stackalloc int[10];
}

4.5 Swift / Kotlin

nullability를 타입 시스템에 넣어 null pointer 문제를 크게 줄인다.

var name: String = "abc"
name = null            // compile error
var maybeName: String? = null

var name: String = "abc"
var maybeName: String? = nil

배열 범위 초과는 trap/exception 계열로 처리되어, UB로 조용히 붕괴하는 대신 실패를 명시적으로 드러낸다.

4.6 Python / JavaScript

C식 UB가 거의 없다. 대신 런타임 오류나 특이한 정의된 동작이 많다.

arr = [1, 2, 3]
arr[10]   # IndexError

const arr = [1, 2, 3];
console.log(arr[10]);   // undefined

JavaScript는 UB 대신 undefined, NaN, implicit coercion 같은 다른 종류의 혼란이 있다. 컴파일러가 "이 상황은 불가능"이라고 가정해 프로그램 전체 의미를 무너뜨리는 방식은 아니다.

4.7 Ada / SPARK

범위 타입, 런타임 체크, 강한 타입 시스템을 제공한다.

subtype Percent is Integer range 0 .. 100;

SPARK는 Ada의 검증 가능한 부분집합으로, 수학적 증명과 정적 분석으로 overflow/범위 초과/data race를 줄이는 데 초점을 둔다.

방산/항공/철도 같은 safety-critical 분야에서 C보다 자연스러운 선택이 되는 경우가 있다고 하지만 굳이 Ada를 써야할까?

4.8 명시적으로 정의된 동작: C# checked / Java overflow

C#은 정수 overflow에 대해 checked(예외)와 unchecked(wraparound)를 선택할 수 있고, 선택한 동작이 정의되어 있다.

checked {
    int x = int.MaxValue;
    x = x + 1;   // OverflowException
}

Java의 int overflow도 UB가 아니라 2의 보수 wraparound로 정의된다.

int x = Integer.MAX_VALUE;
System.out.println(x + 1);   // Integer.MIN_VALUE

버그를 만들 수는 있지만, 컴파일러가 "overflow는 없다"고 가정해 코드를 재작성하는 종류의 UB는 아니다.

4.9 비교표

4.10 Rice 정리와 "만능 검사기" 문제

UB 검사와 관련된 질문을 하면 보통 이런 생각을 한다.

그럼 컴파일러나 정적 분석기가 모든 UB를 미리 찾아주면 되는 거 아닌가?

일반적인 UB 탐지는 정지 문제와 같은 결정 불가능성에 걸린다. 예를 들어 "이 프로그램이 어떤 입력에서 0으로 나누는가?" 같은 질문에는 임의의 프로그램 P의 종료 여부를 그대로 심을 수 있다. P가 멈추는지를 0으로 나누는지로 바꿔 물을 수 있다면, 후자를 푸는 만능 검사기는 곧 정지 문제를 푸는 기계가 된다. 그런 기계가 있었으면 좋겠지만, 아쉽게도 없다.

Rice 정리는 이 한계를 한 문제에서 의미적 성질 전반으로 넓힌다. 계산 가능한 함수의 비자명한 의미적 성질을 일반적으로 판정하는 알고리즘은 존재하지 않는다는 것이다.[13] 즉 "0으로 나누는가" 하나만 막힌 게 아니라, 프로그램이 실제로 무슨 일을 하는지에 관한 질문 대부분이 같은 벽에 걸린다. 구체적으로는 이런 것들이다.

• 이 포인터가 실행 시점에 항상 유효한가?

• 이 정수 덧셈은 어떤 입력에서도 overflow하지 않는가?

• 이 배열 접근은 모든 경로에서 범위 안인가?

• 이 두 스레드는 실제 실행에서 data race를 만들지 않는가?

• 이 함수는 특정 입력에서 반드시 종료하는가?

정적 분석은 이런 질문에 실행 전 답을 요구한다. 일반적인 경우에는 위의 undecidability 벽에 그대로 부딪힌다. 정지 문제가 결정 불가능하다는 것 자체는 Turing의 1936년 논문이 보인 고전적 결과다.[14]

여기서 주의할 점은 Rice 정리와 정지 문제로 설명할 수 있는 한계는 “임의의 일반 프로그램 전체”에 대한 한계라는 점이다. 즉 입력 크기, 루프 횟수, 재귀 깊이, 힙 상태, 스레드 interleaving 등이 원리적으로 제한되지 않는 튜링 완전한 프로그램에 대해, 모든 UB 가능성을 완전하고 자동으로 판정하는 만능 검사기는 존재하지 않는다는 뜻이다.

반대로 분석 대상을 충분히 좁힌다면,
예를 들어 루프 횟수가 고정되어 있고, 재귀가 없고, 메모리 영역과 입력 범위가 유한하며, 가능한 상태 수가 전부 열거 가능한 임베디드 코드나 하드웨어 모델이라면 원리적으로 모든 상태를 탐색할 수 있다.
이 경우에는 model checking이나 exhaustive analysis가 가능하다. 물론 상태 수가 유한하다는 말이 분석 비용이 작다는 뜻은 아니긴하다. 상태 수가 유한하더라도 충분히 많을 경우엔, 상태 폭발 때문에 현실적으로는 여전히 매우 비쌀 수 있다.

흔히 많은 프로그래머가 하는 착각중에 “정적 분석은 수학적으로 언제나 완벽할 수 있다”가 있는데, 정확히 말해서는

“일반적인 C/C++ 프로그램 전체에 대해 모든 UB를 완전하게 잡는 일반 알고리즘은 존재하지 않는다. 그래서 실무 도구들은 false positive, false negative, 분석 대상 제한, annotation 요구 중 하나를 선택한다”라는게 조금 더 정확하다.
일단 그 중에서 정적 분석기의 선택지를 보자

정적 분석기의 선택지:

만능 UB 탐지기는 일반 알고리즘으로 기대할 수 없다. 그런 도구는 사실상 "모든 버그를 찾아주는 컴파일러"에 가깝다. 그쯤 되면 컴파일러가 아니라 점집이다.

이론적 한계가 실무 도구를 무력화한다는 뜻은 아니다.
일반해가 없으므로 좁은 문제로 잘라서 푼다.

• sanitizer는 실행된 경로에서 UB를 잡는다.

• static analyzer는 보수적으로 의심 지점을 찾는다.

• type system은 애초에 위험한 표현을 못 쓰게 한다.

• fuzzing은 사람이 생각 못 한 입력을 밀어 넣는다.

• MISRA/CERT 같은 규칙은 위험한 C 부분집합을 못 쓰게 만든다.

Rice 정리는 "왜 도구를 여러 개 써도 마지막에 사람이 봐야 하는가"를 설명한다. C/C++ UB 검사는 수학적 한계와 비용이 겹친다. 이것이 이 문제가 유난히 피곤한 이유다.

5. 실무 대응

C/C++는 여전히 성능, ABI, OS, 임베디드, 게임 엔진, 드라이버, 레거시 코드에서 쓰인다. 2026년 기준으로는 "잘 조심해서 쓰면 됨"보다 "도구를 켜고, 규칙을 정하고, 위험 구역을 표시해야 함"에 가깝다.

• sanitizer (ASan, UBSan, TSan)

• static analyzer

• fuzzer

• 컴파일러 경고 최대화

• MISRA / CERT 규칙

• 코드 리뷰

• LLM 보조 UB 감사

• unsafe 경계 문서화

새 C/C++ 코드라면 최소한 sanitizer 빌드를 하나 둔다.

clang -Wall -Wextra -Wpedantic -Wconversion -Wshadow -fsanitize=undefined,address -fno-omit-frame-pointer main.c

gcc -Wall -Wextra -Wpedantic -Wconversion -Wshadow -fsanitize=undefined,address -fno-omit-frame-pointer main.c

UBSan은 실행 중 여러 UB를 잡기 위한 도구다. Clang 문서는 UBSan이 컴파일 타임 instrumentation을 삽입해 out-of-bounds, 잘못된 shift, null/misaligned pointer dereference, signed integer overflow 등을 런타임에 포착한다고 설명한다.[9]

sanitizer는 증명기가 아니다. CCTV를 달았다고 도둑이 존재하지 않는 것은 아니다. 찍힌 도둑을 더 잘 볼 수 있을 뿐이다.

• 실행된 경로만 잡는다.

• 모든 UB를 잡지 못한다.

• 최적화/빌드 옵션에 따라 보이는 문제가 달라질 수 있다.

• 커널/임베디드/실시간 환경에서는 런타임 사용이 제한될 수 있다.

• sanitizer를 켰다고 프로덕션 성능/동작이 같다고 보면 안 된다.

도구 조합 예:

성숙하고 엄격하게 작성되기로 유명한 코드베이스(예: OpenBSD)에 LLM 감사를 붙여도 UB 후보가 쏟아지고, 실제 out-of-bounds write가 발견되어 패치된 사례가 있다. LLM 감사도 한계가 있다.
찾아낸 항목을 확인하려면 결국 전문가 인간이 필요하다.
이 작업은 청소에 가깝지만, 막상 빗자루를 잡으려면 표준 문서와 어셈블리를 같이 봐야 한다. 솔직히 이걸 전부 할 수 있을까?[1]

요약:

C/C++는 실패를 "정의하지 않음"으로 밀어내고, 현대 언어들은 실패를 "컴파일 오류, 런타임 예외, unsafe 경계, 명시적 wraparound" 중 하나로 끌어올린다.

UB는 "내 머신에서 됨"과 "표준상 valid함" 사이의 거리정도로 표현할 수 있을 것이다.

같이 보기

• cpp_idioms

• 프로그래밍 이디엄

• C++ 메모리 안전성 논쟁

• x86_메모리_관리의_진화

참고문헌

[1] Everything in C is undefined behavior. Thomas Habets, 2026-05-19. 다양한 UB 사례와 OpenBSD LLM 감사 일화를 다룬 글. ↩

• blog.habets.se: Everything in C is undefined behavior - 정렬, isxdigit, float-to-int, null pointer, varargs, integer promotion 사례와 OpenBSD LLM 감사 일화

[2] C23 표준에서 인용된 절들. 본문 사례의 근거 조항.

• 6.3.2.3 (pointers, null pointer) - 정렬되지 않은 포인터, NULL과 객체/함수의 비교

• 6.3.1.4 (real floating to integer) - float-to-int 변환 범위 초과 UB

• 7.4 (character handling), 6.2.5 (char signedness 구현 정의) - isxdigit(char) 문제

• 6.5.4.2(Address and indirection operators)

[3] A Guide to Undefined Behavior in C and C++. John Regehr. UB 입문의 고전. ↩

• blog.regehr.org: A Guide to Undefined Behavior, Part 1 - 컴파일러가 "UB는 일어나지 않는다"를 전제로 코드를 변환하는 메커니즘

[4] What Every C Programmer Should Know About Undefined Behavior. Chris Lattner, LLVM Project Blog (3부작). ↩

• Part 1 - UB가 성능 최적화를 가능하게 하는 원리

• Part 2 - null check 제거 등 놀라운 효과, Linux/OpenSSL/glibc 피해 사례

[5] UB의 의미론과 최적화 동기. 보충 관점.

• Raph Levien: With Undefined Behavior, Anything is Possible - portable/semi-portable/standard C 진영 구분, strict aliasing

• Paul J. Lucas: Undefined Behavior in C and C++ - "nasal demons"(John F. Woods, comp.lang.c, 1992) 기원과 disappearing if 사례

[6] cppreference. ↩

• cppreference: Undefined behavior

• cppreference C: Behavior categories

• cppreference: Implicit conversions / integer promotion

[7] C++ working draft. ↩

• eel.is C++ draft: Definitions - undefined behavior, implementation-defined behavior 등 용어 정의

[8] cppreference C++. ↩

• cppreference C++: Undefined behavior - signed overflow, out-of-bounds, uninitialized scalar, invalid scalar, null pointer 등 예시

[9] Clang UndefinedBehaviorSanitizer. ↩

• LLVM Clang documentation: UndefinedBehaviorSanitizer - UBSan의 목적, 감지 가능한 UB 종류, 사용법

[10] SEI CERT C Coding Standard.

• SEI CERT C Coding Standard - C에서 UB와 취약점으로 이어지는 규칙 모음

[11] C++ Core Guidelines.

• C++ Core Guidelines - lifetime, bounds, type safety, resource safety 관련 지침

[12] What every compiler writer should know about programmers.

• Wang et al. "What Every Compiler Writer Should Know about Programmers" - C의 UB와 최적화/프로그래머 기대 사이의 충돌을 다룬 논문

[13] Rice's theorem. ↩

• H. G. Rice. "Classes of Recursively Enumerable Sets and Their Decision Problems". Transactions of the American Mathematical Society, 74(2), 358-366, 1953.

• Wolfram MathWorld: Rice's Theorem

[14] Turing and undecidability. ↩

• Alan M. Turing. "On Computable Numbers, with an Application to the Entscheidungsproblem". 1936.

[15] Intel Corporation. Intel® 64 and IA-32 Architectures Software Developer’s Manual,Vol. 3A, §8.1.1 “Guaranteed Atomic Operations”. ↩

x86/Intel 계열에서 원자성이 보장되는 메모리 접근 조건과 cache-line/page split access의 예외를 설명한다.

cdrdv2-public.intel.com

분류: 정의되지 않은 동작 | C++ 메모리 안전성 논쟁 | 프로그래밍 이디엄 | WIKI