> One thing that was a little annoying was their discussion about purpose of undefined behavior. That is, I don't believe "undefined behavior" in the C Language

> One thing that was a little annoying was their discussion about purpose of undefined behavior. That is, I don't believe "undefined behavior" in the C Language exists for speed as such. Rather, undefined behavior is machine-specific behavior and it exists in C so the programmer can write machine specific code, the C Language being a "high-level assembly language" or "system-programmer's Swiss army knife". Speed is one outcome, certainly but there are other ways to get speed (a Just In Time Compile can come at least close naive c code). The point isn't speed. The point is "do anything", the point is that a chip designer can write c code and look on his screen to see the resulting assembler and decide where to go from there. If this were really the case, then they would have made the behavior implementation-defined rather than undefined. A lot of the choices of undefined behavior seem like they were made due to the laziness of implementors, especially the purely syntactic ones, e.g. token pasting creating multiple tokens or unmatched quotes. It is pretty crazy that a C compiler is allowed to do anything if you miss a closing quotation.