LLVM IR_{intermediate representation}과 C 언어 모두 "undefined behavior"란 개념이 있습니다. Undefined behavior는 여러 뜻을 가지는 매우 넓은 개념이며, John Regehr blog 에서 잘 소개되어 있습니다. 요약하면, C 언어에서 일리가 있다고 여겨지는 많은 부분도 사실 undefined behavior를 가지고 있으며, 여러 버그의 원인이 된다는 것입니다. 나아가서, C 언어의 undefined behavior는 (컴파일러와 런타임 모두 포함) implementation이 하드 디스크를 포맷하거나, 전혀 엉뚱한 일을 하거나, 심각한 문제를 발생시켜도 전혀 문제될 것이 없다는 것을 나타내고 있습니다. 다시 강조하지만, 꼭 John Regehr씨의 blog를 읽어보기 바랍니다_{또, C FAQ의 11.33을 읽어보기 바랍니다.}

Undefined behavior가 존재하는 이유는, C 언어 설계자가, 매우 효율적인 저수준 프로그래밍 언어로 C 언어를 만들었기 때문입니다. 이와 반대로 Java와 같은 (여러 'safe'한 언어들 포함) 언어는, 안전하고 어떤 implementation에서 동작하더라도 같은 결과를 얻길 원했기 때문에, undefined behavior가 거의 없습니다. 그 대신 성능을 일부 포기했습니다. 두 방식 모두 완벽하다고 할 수는 없지만, 적어도, C 언어 프로그래머라면 undefined behavior가 무엇인지는 알아야 합니다.

먼저, 컴파일러가 빠른 성능을 얻기 위해 수행하는 최적화 작업에 있어서, 만병통치약은_{magic bullet} 없습니다. 컴파일러가 최적화를 수행하는 방식을 간단하게 훑어보면, a) register allocation, scheduling등과 같은 간단한 작업이 있고 b) peehole optimization이나 loop transformation과 같은 여러가지 트릭을 가능한 적용하며, c) 가능한 불필요한 abstraction을 없애고, (이 원인으로는 C macro, inline function, C++에서 temporary object 등이 있습니다) d) 앞 작업들을 수행할 때, 원래 의미를 망치지 않아야 합니다. 이 작업들이 별 것 아닌것 같지만, (codec 등에서) 반복되는 작업에서 한 cycle이 달라질 경우, 전체 작업이 10% 빨라지거나, 10% 전력을 덜 소모할 수도 있습니다.

Undefined behavior를 좀 더 깊게 파해치고, LLVM C 컴파일러의 policy를 살펴보기 전에, undefined behavior의 몇 가지 예를 들어서 왜 몇몇 undefined behavior가 (Java와 같은 안전한 언어에 비해) 성능 향상에 도움이 되는지 설명하려고 합니다. 크게 두 가지가 있는데, 하나는 undefined behavior로 인해 가능한 최적화 기법들, 하나는 undefined behavior로 인해 overhead를 피하는 법이 있습니다. 물론 모든 경우에 이를 수행할 수 있는 것은 아니며, 모든 경우를 다 해결하기 위해서는 halting program 문제_{Halting problem 참고} 포함 여러 어려운 문제를 풀어야 합니다.

한가지 알아둘 점은, C 언어 표준이 undefined behavior라고 명시한 것 중 일부에 대해서는 Clang과 GCC에서 확실히 정의하고 있습니다. 즉 일부에 대해서는 더 이상 undefined behavior가 아닌 셈입니다. 이 장에서 설명할 내용들은 표준에서 undefined behavior로 명시한 것이며, 이 두 컴파일러에서도 (default mode에서) undefined behavior라고 정의한 것들입니다.

현대 컴파일러의 optimizer는 지정된 순서로 여러 최적화를 수행합니다. 때때로 이러한 최적화는 반복되어 수행되며, 컴파일러가 향상될 때마다 최적화가 달라질 수 있습니다. 또, 서로 다른 컴파일러는 매우 다른 optimizer를 가지고 있습니다. 최적화가 각각 다른 단계에서 수행되기 때문에, 앞 최적화 단계에서 이루어진 코드 변경 덕택에 엉뚱한_emergent 현상이 발생할 수도 있습니다.

현실적인 예제로, (Linux Kernel에서 발견된 버그의 간단한 버전인) 아래 코드를 보기 바랍니다:

void contains_null_check(int *P) {
  int dead = *P;
  if (P == 0)
    return;
  *P = 4;
}

위 코드는 분명하게 null pointer를 검사하고 있습니다. 만약 컴파일러가 "불필요한 null 검사_{redundant null check}" 단계 전에 "죽은 코드 제거_{dead code elimination}"을 수행한다면, 위 코드는 아래 두 단계로 변경될 것입니다:

다음으로 아래처럼 변경됩니다:

void contains_null_check_after_DCE(int *P) {
  if (P == 0)
    return;
  *P = 4;
}

하지만, optimizer가 이 두 최적화를 반대 순서로 수행했다면, 즉, DCE 전에 RNCE를 수행한다면, 코드가 아래 두 단계로 변경될 수 있습니다:

void contains_null_check_after_RNCE(int *P) {
  int dead = *P;
  if (false)  // P was dereferenced by this point, so it can't be null 
    return;
  *P = 4;
}

그리고, DCE가 수행되어 아래처럼 바뀝니다:

void contains_null_check_after_RNCE_and_DCE(int *P) {
  //int dead = *P;
  //if (false)
  //  return;
  *P = 4;
}

분별력있는_reasonable 프로그래머라면, 컴파일러가 null 검사를 없애버렸다는 사실에 매우 놀랄 것입니다. (그리고 컴파일러 버그를 보고하겠지요) 하지만, 표준에 따르면, "DCE후에 RNCE"와 "RNCE 후에 DCE" 모두 올바른 최적화 방법이며, 두 최적화 기법 모두 다양한 프로그램에서 성능 향상을 위해 사용되는 중요한 기법입니다.

위 예는 매우 의도적으로 만든 간단한 코드이지만, inline 덕택에 이러한 일들이 매우 자주 일어납니다: inline으로 추가한 함수는 부가적인 최적화 기법을 적용할 기회를 제공하게 됩니다. 즉, optimizer가 함수를 inline으로 하겠다는 것을 결정하면, 여러 local 최적화 단계가 수행되며, 이에 따라 코드의 동작 방식이 바뀔 수 있습니다. 이는 표준에 따라 정당한 것이며, 현실적으로 성능 향상에 매우 중요한 기법입니다.

C 계열의 언어는 다양한, 보안이 중요한 코드, 예를 들어 kernel 또는 setuid daemon, web browser등의 프로그램을 작성하는데에 쓰입니다. 이런 프로그램들은 의도적인 공격이 담겨있는 적대적인 입력 데이터를 받을 수 있으며, 버그가 있을 경우, 여러 보안 문제를 일으킬 수 있습니다. 다행히도, (널리 알려진) C 언어의 한가지 장점은, code를 읽으면서, 실제 시스템에서 일어나는 일을 쉽게 파악할 수 있다는 것입니다.

그러나, undefined behavior 때문에 이런 장점이 가려지는 경항이 있습니다. 결국, 대부분 프로그래머들은 앞에서 다룬 null 검사 코드가 실제로 null을 검사할 것이라고 추측할 것입니다. 별로 놀라워하지 않을 수도 있지만 (왜냐하면, null check를 하지 않더라도, 그 다음 store 연산에서 프로그램이 crash할 것이므로), 이외에도 정상적으로 보이는 C 코드가 실제로는 전혀 엉뚱한 일을 하는 경우가 많습니다. 이러한 문제가 (Linux kernel, OpenSSL, glibc 등) 여러 프로젝트에 영향을 주었으며, CERT가 GCC 대상으로 보안 약점 보고를 만들게 되었습니다. (저자: 제 개인 의견으론 이는 단순히 GCC 문제가 아니며, 최적화 기능이 있는 대부분 C 컴파일러 모두 해당된다고 생각합니다.)

예를 들어, 다음 C 코드를 보기 바랍니다:

void process_something(int size) {
  // Catch integer overflow.
  if (size > size+1)
    abort();
  ...
  // Error checking from this code elided.
  char *string = malloc(size+1);
  read(fd, string, size);
  string[size] = 0;
  do_something(string);
  free(string);
}

위 코드는 malloc⁠이 파일에서 읽은 데이터를 저장할 수 있는 충분한 공간을 확보하도록 (이때, nul terminator를 위해 추가 byte 확보) 검사하며, 이 때, integer overflow가 일어날 경우, 더 이상 작업을 수행하지 않도록 합니다. 그러나, 이 코드는 이전 Section에서 설명했던 signed integer overflow 문제를 그대로 갖고 있습니다. 즉, 컴파일러 optimizer가 위 코드의 검사 코드를 제거할 수 있습니다. 따라서 컴파일러는 아래와 같은 코드를 생성할 수 있습니다:

void process_something(int *data, int size) {
  char *string = malloc(size+1);
  read(fd, string, size);
  string[size] = 0;
  do_something(string);
  free(string);
}

64-bit 플랫폼을 예로 들면, size⁠가 (아마도 디스크의 파일 크기가) INT_MAX⁠일 경우, 이는 attacker가 이용해 먹을 수 있는 버그가 됩니다. 이것이 얼마나 끔찍한 것이나면: 코드를 검사하는 사람_auditor이 이 코드를 보고, 적절한 overflow 검사가 있다고 판단할 것이고, 테스트하는 사람은 구체적인 에러 경우를 검사하지 않은 한, 문제가 없다고 판단할 것이며, 이 코드는 안전하다고 결론이 날 것이니나, 누군가 이 헛점을 악용하는 경우가 발생하게 될 것입니다. 결국, 이는 놀랍지만, 꽤 심각한_scary 버그입니다. 다행히도, 이 경우에는 문제가 간단합니다. 위 검사 대신 size == INT_MAX=⁠ 또는 이와 비슷한 코드를 쓰면 됩니다.

드러난 것처럼, integer overflow는 여러가지 이유로 인하여 보안상 문제가 됩니다. 완벽하게 정의된_defined integer 연산을 쓰더라도 (예를 들어 -fwrapv 옵션을 쓰거나 unsigned integer만 사용), 전혀 다른 integer overflow bug가 발생할 수 있지만, 보통 이런 경우는 코드에서 발견하기 쉽거나 대부분 보안 검사자_{security auditor}들이 알고 있는 문제일 것입니다.

일부 개발자, 특히 생성된 machine code를 보는 것을 좋아하는 low level embedded 프로그래머들은 최적화를 활성화시킨 상태에서 개발하곤 합니다. 개발 도중에는 버그가 발생할 경우가 많기 때문에, (최적화를 활성화 시킨 상태에서 개발하게 되면) 놀랄만한 최적화가 불균형하게 일어나게 되어 runtime에 디버그하기 힘든 상황에 처하기 쉽습니다. 예를 들어, 앞 장에서 설명한 zero_array 함수에서 i = 0 초기화 코드를 실수로 빼먹었다면, 컴파일러는 (초기화되지 않은 변수를 쓰는 것은 undefined이므로) 전체 반복문을 제거할 수도 있기에, 결국 zero_array 함수는 단순한 return;⁠으로 전락하게 됩니다.

다른 예로, (global) function pointer를 쓰는 경우를 살펴보겠습니다:

static void (*FP)() = 0;

static void impl() {
  printf("hello\n");
}

void set() {
  FP = impl;
}

void call() {
  FP();
}

Clang⁠은 위 코드를 아래와 같이 최적화합니다:

void set() {}

void call() {
  printf("hello\n");

}

왜냐하면, null pointer를 호출하는 것은 undefined이므로, 컴파일러는 call 함수를 호출하기 전에 반드시 set 함수가 호출되어야 한다는 것으로 가정하게 되기에 이런 코드 생성이 가능하게 됩니다. 개발자가 set 함수를 호출하는 것을 빼먹은 상황이지만, (최적화를 활성화 시켰기 때문에) 이런 식으로 동작하는 게 가능하게 된 것입니다. 만약 (debug mode 등) 최적화를 끈 상태에서 build 했을 경우, null pointer dereference로 프로그램이 종료하게 되어, 훨씬 빠르게 실수를 알아차릴 수 있었을 것입니다.

결국, 이 문제는 해결하기 쉽습니다. 이상하게 돌아단가고 의심이 되면, -O0⁠를 써서 최적화를 끄게 되면 문제를 쉽게 발견할 가능성이 높아집니다.

저희는 동작하는 (것처럼 보이는) 프로그램이 새 LLVM으로 build하면 동작하지 않거나, GCC로는 잘 동작하는 프로그램이 LLVM으로 옮겼을 경우, 망가지는 경우를 여러번 봤습니다. 때때로 이는 LLVM의 버그로 인한 것이지만, 대부분의 경우는 프로그램에 잠재하는 버그가 컴파일러에 의해 발견되었기 때문입니다. 이런 버그는 전혀 다른 방향으로 영향을 줄 수 있으며, 여기에서는 두가지 경우를 예로 들겠습니다:

1. 초기화되지 않은 변수를 쓴 코드가 (기존에 운이 좋게도 0으로 초기화되어) 기존에는 동작했지만, 이제 0이 아닌 다른 register를 쓰게 되어 문제를 일으키는 경우, 이는 register 할당_allocation이 바뀔 경우 흔하게 일어납니다.
2. 스택에서 array overflow를 일으키는 코드가 (운이 좋게도 덮어 쓴 부분이 쓰이지 않은 영역이어서) 기존에 동작했지만, 지금은 문제를 일으키는 경우. 이 경우, 컴파일러가 stack에 변수를 배치하는 방식이 바뀌거나, 또는 변수의 lifetime이 겹치지 않는다고 판단될 경우, 같은 stack 영역을 공유하기 때문에 일어납니다.

중요한 점은, 버그가 있는 코드에서 발견된 undefined behavior 때문에, 향후 컴파일러가 어떤_any 최적화라도 마음대로 수행할 수 있다는 것입니다. Inlining, loop unrolling, memory promotion 그리고 다른 최적화 기법이 갈 수록 향상되고 있으며, 한 가지 기법에 의해 최적화된 코드는 다른 최적화가 일어날 수 있는 기회가 되어 또 다른 최적화가 또 수행되게 됩니다.

제가_{원 저자} 보기엔, 이는 매우 불편한 상황입니다. 왜냐하면, 이는 결국 컴파일러를 비난할 원인을 제공하는 것처럼 보이기 때문이기도 하지만, 수많은 C 코드들이 사실상 터지길 기다리는 지뢰밭이라는 것을 뜻하기 때문입니다. 이로 인해 더 큰 문제가 있는데…

앞에서 말한 이 지뢰밭이 생각한 것보다 더 심각한데, 그 이유는, 큰 규모의 application에서 undefined behavior가 없기에 (향후에도) 문제 없다라고 판단할 좋은 방법이 없기 때문입니다. 일부 버그들을 발견하는데 도움을 주는 많은 도구들이 있지만, 향후에도 안전하다라는 보장을 줄 수 있는 도구는 없습니다. 이런 도구들의 장단점에 대해 좀 더 알아보면:

1. The Valgrind memcheck는 초기화되지 않은_{uninitialized} 변수와 기타 메모리 관련 버그를 잡는데 쓸 수 있는 기막히게 좋은_fantastic 도구입니다. 단점은, 이 도구는 꽤 느리다는 것이며, 이는 생성된 machine code에 버그가 있는 경우에만 찾아낼 수 있다는 점입니다. (즉, optimizer가 제거한 코드는 찾을 수 없음). 그리고 프로그램이 C 코드로 작성되었다는 것을 알지 못합니다. 따라서 범위를 벗어나는 shift 문제_{shift-out-of-range}나 signed integer overflow 문제를 찾아낼 수는 없습니다.
2. Clang⁠은 experimental -fcatch-undefined-behavior 모드를 가지고 있으며, 이는 범위를 벗어나는 shift나 간단한 array 범위 에러 등을 검사하는 runtime 검사를 추가해 줍니다. 이는 application runtime을 느리게 하는 단점이 있으며, random pointer dereference와 같은 문제를 발견할 수는 없지만 (Valgrind는 가능), 대신 여러 다른 중요한 버그들을 잡을 수 있습니다. 또, Clang⁠은 -ftrapv 옵션을 완벽하게 지원합니다. (-fwrapv 옵션과 혼동하지 말기 바랍니다.) 이 옵션은 signed integer overflow가 일어날 경우, trap이 일어나도록_{program이 끝나도록} 해 줍니다. (GCC도 이 옵션이 있지만, 제 경험상 버그가 있고 믿을 수 없습니다_unreliable) 아래에 -fcatch-undefined-behavior 데모가 있습니다.

$ cat t.c
int foo(int i) {
  int x[2];
  x[i] = 12;
  return x[i];
}

int main() {
  return foo(2);
}
$ clang t.c 
$ ./a.out 
$ clang t.c -fcatch-undefined-behavior 
$ ./a.out 
Illegal instruction

3. 컴파일러 경고 메시지는 uninitialized variable과 간단한 integer overflow 버그 등, 몇몇 종류의 버그를 잡는데 꽤 도움이 됩니다. 두 가지 제약이 있는데, 1) 실행될 때 코드에 대한 동적 정보가 없으며 2) 이 검사는 컴파일 시간을 늘리기 때문에 매우 빨리 수행되어야 한다는 점입니다. 따라서 제한적일 수 밖에 없습니다.
4. Clang Static Analyzer는 좀 더 깊게 분석하며 (undefined behavior를 쓰거나, null pointer를 dereference하는 등) 버그를 찾아낼 수 있습니다. 이 툴은 (분석 시간에 제약을 받지 않으므로,) 좀 더 향상된 컴파일러 경고 메시지를 만들어 주는 툴이라 생각하시면 됩니다. 단점은 1) 프로그램 실행에서 얻을 수 있는 동적 정보가 없다와 2) 대부분 개발자의 일반적인 작업 방식에 통합되어 있지 않다입니다. (다행히, 이 도구는 이미 Xcode 3.2 버전부터 통합되어 있습니다)
5. LLVM "Klee" Subproject는 symbolic analysis를 써서 코드의 모든 가능한 path를 분석해서, testcase를 생성해 줍니다. 대규모 application에 쓰기에는 현실적이지 않지만_impractical, 그래도 꽤 좋은 툴입니다.
6. 제가_{원 저자} 직접 써 보지는 않았지만, Chucky Ellison씨와 nd Grigore Rosu씨가 만든 C-Semantics tool은 꽤 관심이 가는 툴이며, (sequence point violation과 같은) 종류의 버그를 잡아 줄 수 있습니다. 아직 연구 단계 prototype이지만, (독립적이며 작은) 프로그램 개발에 꽤 도움이 될 수 있습니다. John Regehr씨의 blog⁠를 읽어보시기를 추천합니다.

요약하면, 일정 부분의 버그를 찾는데 도움이 되는 툴은 많지만, 어느 것도, 프로그램에 undefined behavior가 없다는 것을 보장해주지 않습니다. real world에 돌아가는 application에 버그가 많다는 것과, c 언어가 여러 중요한 application에 쓰인다는 것을 생각할 때, 이는 꽤 심각하다고 갈 수 있습니다. 다음 장에서는 C 언어가 undefined behavior를 다룰 때 쓸 수 있는 Clang option들에 대해 알아보겠습니다.

종종 "컴파일러는 undefined behavior에 의존하는 최적화를 수행할 때, 왜 경고하지 않는가"에 대한 질문을 받곤 합니다. 왜냐하면 그런 undefined behavior는 대부분 user code의 버그이기 때문입니다. 그렇게 경고를 하는 게 어려운 이유는, 1) 너무나도 많은 경고 메시지가 발생해서 사실상 쓸모없게 될 가능성이 높기 때문이며, (왜냐하면 bug가 있던 없던 최적화가 수많은 곳에서 일어날 것이기 때문에) 2) 사람들이 원하는 곳에서만 이러한 경고를 발생시키는 것은 까다로우며_tricky 3) 결합된 최적화 기법들이 또다른 최적화가 가능한 기회를 제공하는 것에 대해, 사용자에게 알려줄 방법이 딱히 없기 때문입니다. 한 가지씩 좀 더 자세히 알아보면…

People often ask why the compiler doesn't produce warnings when it is taking advantage of undefined behavior to do an optimization, since any such case might actually be a bug in the user code. The challenges with this approach are that it is 1) likely to generate far too many warnings to be useful - because these optimizations kick in all the time when there is no bug, 2) it is really tricky to generate these warnings only when people want them, and 3) we have no good way to express (to the user) how a series of optimizations combined to expose the opportunity being optimized. Lets take each of these in turn:

현재 undefined behavior와 관련된 상황에서 Clang⁠과 LLVM⁠이 이런 상황을 개선하기 위해 무엇을 제공할 수 있느냐고 물으실 겁니다. 몇가지는 이미 제가 답변했으며: Clang Static Analyzer, Klee project, 그리고 -fcatch-undefined-behavior⁠가 있습니다. 다만 컴파일러만큼 널리 쓰이지는 않고 있기 때문에, 컴파일러에 이러한 기능을 추가하는 것이 훨씬 더 유용할 것이나, 컴파일러 자체는 동적 정보를 알 수 없으며, 컴파일 시간이라는 제약이 있다는 점을 아셔야 합니다.

Clang⁠은 이 문제 해결을 위한 첫 걸음으로, 다른 컴파일러들에 비해 훨씬 많은 경고를 default로 제공합니다. 일부 개발자들은 build할 때 -Wall -Wextra⁠를 쓰도록 훈련받았지만, 대바수는 이러한 옵션이 있는지도 모르며 알고 있다 하더라도 쓰지 않는 것이 현실이기 때문입니다. 좀 더 많은 경고를 하도록 하면 좀 더 많은 버그를 잡아낼 수 있습니다.

두번째로, Clang⁠은 (실수인 것이 ) 명백한, 여러 undefined behavior에 대해 (예를 들어 null dereference, oversized shift 등) 경고를 발생합니다. 이는 앞에서 다루었듯이 완벽하진 않지만, 실제로는 잘 쓰이고 있습니다.

세번째로, LLVM optimizer는 할 수 있는 것보다 훨씬 더 적은 범위의 undefined behavior를 쓰고 있습니다. 언어 표준은 "undefined behavior로 인하여 보장할 수 없는 일이 일어날 수 있다"고 하지만 현실적으로 쓸모있는 정보라고 할 수 없고, 개발자에게 도움이 되지도 않습니다. 대신 LLVM은 다음과 같이 조금 다른 방식으로 최적화를 수행합니다. (죄송하지만, 아래 링크??들은 C 언어 레벨이 아닌 LLVM IR 규칙을 다루고 있습니다.)

The third step is that the LLVM optimizer generally takes much less liberty with undefined behavior than it could. Though the standard says that any instance of undefined behavior has completely unbound effects on the program, this is not a particularly useful or developer friendly behavior to take advantage of. Instead, the LLVM optimizer handles these optimizations in a few different ways (the links describe rules of LLVM IR, not C, sorry!):

1. Clang⁠은 특정 undefined behavior를 찾았을 때, 적절하다고 판단될 경우, 암암리에_implicitly 예외적인_trapping 연산으로 바꿉니다. 예를 들어 아래 C++ 함수는:

int *foo(long x) {
  return new int[x];
}

아래 X86-64 machine code로 변환됩니다:

__Z3fool:
	movl $4, %ecx
	movq %rdi, %rax
	mulq %rcx
	movq $-1, %rdi        # Set the size to -1 on overflow
	cmovnoq %rax, %rdi    # Which causes 'new' to throw std::bad_alloc
	jmp __Znam

GCC의 경우, 아래 machine code로 변환됩니다:

__Z3fool:
	salq $2, %rdi
	jmp __Znam             # Security bug on overflow!

우리(LLVM 측)는, buffer overflow나 프로그램에 심각한 결점_exploit을 가져올 수 있는 심각한 integer overflow bug가 예상될 경우, 추가적인 (CPU) cycle을 투자해서, 이를 막는 것이 훨씬 더 낫다고 판단했기 때문에 위와 같은 차이가 있습니다. 어차피 new 연산자의 경우 꽤 비싼 연산이기 때문에, 추가된 overhead의 영향은 거의 느낄 수 없는 수준입니다. GCC 측은 이 문제를 적어도 2005년부터 알고 있었지만, 이 글을 쓰는 시점에도 고치지 않고 있습니다.

역자 주: GCC도 이제 이 기능을 가지고 있습니다. (Version 4.9.3에서 확인)

2. undefined value를 다루는 사칙연산은 undefined behavior를 낳지 않고, undefined value를 낳도록 설계했습니다. 따라서 사칙 연산으로 인해 하드 디스크를 포맷하는 등의 undefined behavior는 발생하지 않습니다. 또한 이러한 사칙연산도, undefined value의 범위를 최소화하였습니다. 예를 들어 "undef & 1" 연산은 하위 1 bit만 undefined 값이며 나머지 bit들은 항상 0이 나오도록 만들었습니다. 따라서 LLVM으로 한정할 경우, ((undef & 1) >> 1)⁠은 undefined가 아니라 항상 0입니다.
3. 동적으로 (signed integer overflow 등) undefined operation이 실행될 경우, logical trap value가 생성되며, 이는 이후 관련된 계산에 영향을 미치지만, 전체 프로그램을 망가트리지는 않습니다. 이런 이유로, optimizer는 초기화 되지 않은 변수를 사용하는 코드를 제거하게 됩니다.
4. null 포인터를 통해 값을 저장하려 하거나 null pointer를 호출_call하는 코드는 명백한_obviously unreachable한 코드이기 때문에, 최적화 단계에서, 기존에는 이런 block들을 지워버렸습니다. (잘난 체하기 좋아하는 언어 학자 입장에서는) 이것이 매우 정상적인_{strictly true} 것으로 보이지만, null pointer를 dereference하는 실수는 매우 자주 발견되며, 따라서 이 코드가 지워질 경우, 바로 다음 코드가 실행되는 것 때문에 이 버그를 발견하기가 매우 어렵다는 것을 깨달았습니다. 그래서 우리는 Clang⁠이 (이런 코드를 지우는 대신) __builtin_trap()⁠가 호출되도록 하여, 문제를 일으키는 코드가 바로 runtime trap을 일으키도록 바꿨습니다. 이 결정의 단점은 이러한 검사를 하는 부분과 trap을 일으키는 overhead가 있다는 점입니다.
5. Optimizer는 프로그래머 의도를 파악할 수 있는 경우 (예를 들어 P⁠가 float⁠을 가리키는 pointer일 때, *(int *)P), 이를 프로그래머의 의도대로 처리하도록 했습니다. 여러 경우에 대해 이는 매우 도움이 되지만, 여기에 의존하는 것은 좋은 습관이 아닙니다. 그리고 여러 단계의 변환을 거친 경우, 당연히 동작해야 할 것 같지만, 그렇지 않은 경우가 많으므로 주의해야 합니다.
6. 위에 해당하지 않는 경우, 즉, Part 1에서 다룬 zero_array⁠나 set/call 예제의 경우에는, 사용자에게 아무런 경고_notification도 알리지 않고 최적화 됩니다. 그 이유는, 이 때 우리가 사용자에게 알려줄 쓸만한 정보도 없고, 또, 이런 최적화에 의해서 동작하는 (버그가 잠재되어 있는) 코드가 망가질_broken 경우는 드물기 때문입니다.

우리가 개선할 수 있는 부분은 trap 추가에 관한 것입니다. Default로 off 이지만, 경고 옵션을 추가해서 trap instruction을 생성할 때마다 경고를 할 수 있다면 꽤 괜찮을 것이라 생각합니다. 어떤 코드에 대해서는 너무 의미없는 경고가 많이 발생할 수 있겠지만, 다른 코드에 대해서는 의미가 있을 수도 있으니까요. 이를 위해서는 optimizer가 경고를 발생시킬 수 있도록 수정되어야 할 것입니다. 현재로는 debugging 정보 추가 옵션이 on되어 있지 않는 한, 최적화 단계에서 소스 코드 위치를 알 방법도 없습니다. (수정될 가능성은 있음)

가장 어려운 부분은, 경고 단계에서 대상 코드가 (예를 들어) loop를 unrolling해서 나온 것인지, 네번의 함수 호출을 inline해서 나온 것인지 추적할 정보가 없다는 것입니다. 잘해봐야 우리가 할 수 있는 것은, 코드의 원래 위치, 즉 file/line/colum을 알려주는 것이며, 대부분 경우, 이 정보로도 충분하겠지만, 이 정보만으로도 부족할 수 있을 것입니다. 이런 기능은 우리가 해야 할 일 중에서 우선 순위가 낮은데, 첫째, 크게 쓸모있어 보이지도 않고, 둘째, default로 기능을 on할만한 것도 아니며, 세째, 꽤 많은 작업이 필요하기 때문입니다.

최고의 성능을 얻는 것에 큰 관심이 없다면, 여러가지 컴파일러 옵션을 써서 가능한 undefined behavior가 발생하지 않게 하면 됩니다. 예를 들어 -fwrapv 옵션을 쓰면 signed integer overflow에서 undefined behavior가 발생하지 않습니다. (그렇지만 이 옵션이 integer overflow로 인한 보안 문제를 해결해 주지는 않습니다). -fno-strict-aliasing 옵션을 쓰면 Type Based Alias Analysis를 끌_disable 수 있습니다. 그래서 type 관련 규칙을 무시할 수 있습니다.

또, 사용자에게서 요청이 충분히 많다면, 우리가 Clang⁠에 옵션을 추가해서 모든 local variable을 0으로 초기화하는 옵션을 넣을 수도 있을 것이며, "and" 연산을 모든 shift 연산 앞에 추가하여 줄 수도 있습니다. 그렇다 하더라도 C 언어에서 undefined behavior를 완벽하게 제거하면서 ABI 호환성을 유지하고, 성능을 유지하는 것은 불가능합니다. 다른 관점에서 보면, 이 경우, 여러분은 C 언어를 쓰는 것이 아니라 portable하지 않은, C와 비슷한 언어를 쓰는 것이 되어 버릴 것입니다.

Portable하지 않는, C와 유사한 언어를 쓰는 것에 만족할 수 없을 경우, (앞에서 다룬 여러 툴들과 함께) -ftrapv, -fcatch-undefined-behavior 옵션을 debug build에서 쓰는 것이, 버그를 빨리 찾는데 도움이 됩니다. 또한 보안에 민감한 프로그램을 만든다면 release (production) 단계에서 이 옵션을 계속 쓰는 것도 의미가 있습니다. 이 옵션들이 모든 버그를 잡아 줄 수는 없지만, 일부는 잡을 수 있을 것입니다.

결과적으로, 가장 근본적인 문제는, (인기가 매우 많음에도) C 언어가 안전한_safe 언어가 아니며, 많은 사람들이 언어가 어떻게 동작하는지 정확히 이해하고 있지 않다라는 것입니다. 1989년 C 언어 표준이 제정되기 전에, C 언어는 "PDP Assembly 언어를 가볍게 wrapping한 저수준 시스템 프로그래밍 언어"이었다면, 거기서 발전해서 현재 "대부분 사람의 예상을 (좋지 않은 방향으로) 깨트리면서, 우수한 성능을 내는 저수준 시스템 프로그래밍 언어"가 되었습니다. 달리 말하면, 대부분 사람의 기대를 저버리면서까지 성능에 집착한 언어이며, 이로 인해 정말 어려운 시기에 사람들의 뒤통수를 치는 언어가 되었습니다.

마지막으로, C 언어는 매우 놀라운 성능을 보여주는, portable한 assembler 그 이상입니다. 지금까지 내용이 (적어도 컴파일러 개발자 입장에서 ) C 언어에서 undefined behavior와 그 이면을 보여주는데 도움이 되었으면 합니다.