> It's the compiler's job to make code that is as fast as possible. This doesn't used to be the case, or we would have had something more like FORTRAN, with le

> It's the compiler's job to make code that is as fast as possible. This doesn't used to be the case, or we would have had something more like FORTRAN, with less pointers that alias all over the place. C was build so the programmer could optimise the program. The design of C was pretty hostile to compiler optimisations, to the point that some PL researchers say its wide adoption set us back decades. It's only later that compilers started to really optimise stuff themselves. And they used undefined behaviour to do so. Signed integer overflow UB for instance was used to optimised `for` loops, thus compensating the verbose, hard to optimise original design. > It's not that the C compiler authors are out to get you The end result is the same. "Oh, this code leads to undefined behaviour. Let's pretend it's dead, it will be faster that way". Apply that to reasonable looking, yet incorrect, safety checks (like checking for integer overflow after the fact), and just like that you have a buffer overflow and an arbitrary code execution exploit.