I would prefer the program always exited on undefined behavior. That would be a hell of a lot more secure than it continuing going potentially blowing the stack or letting the attacker call arbitrary code. It’s the same with memory allocators: if malloc() fails to allocate new memory, I don’t want it to return a NULL. I want it to use a static buffer to log the problem and then exit the process. There is almost never anything you can do when you run out of heap and if you can you aren’t naively using malloc() from your system library and checking for NULL return values.

The whole problem with undefined behavior is that it is faster to not check for undefined behavior and calling exit(1) (exit(0) would be a successful exit). Think about it in slightly higher terms: you implement a linked list that can search for an item and return a pointer to it once it finds it. Your implementation explicitly says that if you search for an item that isn’t in the list you will hit an infinite loop. I disregard the warning and let it search for an item not in the list. I hit an infinite loop. Could you have added a check for “if (current == head)” and bail then returning NULL? Sure you could but that introduces a branch and slows things down. Better label what can happen as undefined behavior because maybe on some future processor you’ll have that check because it’s cheap but on x86 it isn’t so you don’t. This is essentially the same thing.

> if malloc() fails to allocate new memory, I don’t want it to return a NULL. I want it to use a static buffer to log the problem and then exit the process. There is almost never anything you can do when you run out of heap and if you can you aren’t naively using malloc() from your system library and checking for NULL return values.

In C's defence, you can easily get this behaviour by wrapping malloc in a safe_malloc function. Given that C lacks exceptions, it makes good sense to handle unable-to-allocate by returning NULL as this leaves the door open to all possible strategies.

> Once the compiler encounters undefined behavior, it's free to do whatever it wants. like, produce an executable that does exit(0); when it hits that condition. Compiler writers are generally ethical people that won't do that

This is wrong on two points.

Firstly, real world compilers very often do handle various kinds of undefined behaviour with immediate termination. On many platforms, dereferencing a null pointer will result in a segfault. Sometimes compilers generate code to trap if undefined behaviour would result. In the C++ standard, some errors are defined to result in a call to std::terminate, rather than undefined behaviour. [0]

Secondly, as IgorPartola indicates, doing this isn't irresponsible, it's the least bad way to handle undefined behaviour. If your loop has overrun the end of your array, you generally don't want the execution to silently proceed with invalid data, you want execution to end immediately.

[0] https://stackoverflow.com/a/43675980/