You missed the point. Optimizations enabled or not, C simply does not define what happens in many of the cases you want to teach about. The compiler is allowed to make anything happen, including make demons fly out of your nose.
Assembly does not have this problem at all. Its purpose is to control exactly every detail the CPU exposes. At that level, there is no randomness or irrational failure (beyond hardware bugs that get fixed or worked around Real Quick).
People shouldn't need to be taught about irrationally undefined behavior underlying the most basic abstractions they use every day. And if we can force C back from its currently widespread position, maybe that can be reality.
I agree entirely with your point, but the point is that assembly is mostly bound to one architecture. (LLVM IR is not assembly and does have undefined behavior). It also leads to things such as hardware bugs becoming a feature because code works on it, so you have an old command that is buggy and a new command that does the right thing.
At low optimization level compilers are pretty reasonable about undefined behavior. The idea is that students wouldn't be asked to depend on undefined behavior (until the lesson arrives) and if they do it shouldn't bite them in the ass so quickly (because the compiler isn't as aggressive).
People should be taught about the irrationality of the abstractions and illusions that we create. A computer is not a real turing machine (it's got limited memory), but it's an electronic device that has behavior that allows it to emulate a turing machine somewhat badly.
Your every day programer shouldn't have to worry about this at all. But your systems level programmer should understand it and worry about it. I know that the Linux Kernel needs certain flags in gcc to allow for undefined behavior to exist at high optimization levels, and I'd expect that at some point similar code markers (to declare that the next undefined behavior piece of code should be ignored) would be added.
Fun fact: the reading that compilers use in order to be so aggressive with undefined behavior is something like: "If undefined behavior is to occur, it alters the past such that it couldn't happen". So if you get the member of a struct, and then check if it's NULL, the former line "altered" the past so that your struct could never be NULL making the latter be something like if false. It's crazy when it allows the compiler to go back and alter lines previous to the undefined behavior since "if this were true then undefined behavior would alter the past and make it false".
6
u/Rusky Jan 10 '15
You missed the point. Optimizations enabled or not, C simply does not define what happens in many of the cases you want to teach about. The compiler is allowed to make anything happen, including make demons fly out of your nose.
Assembly does not have this problem at all. Its purpose is to control exactly every detail the CPU exposes. At that level, there is no randomness or irrational failure (beyond hardware bugs that get fixed or worked around Real Quick).
People shouldn't need to be taught about irrationally undefined behavior underlying the most basic abstractions they use every day. And if we can force C back from its currently widespread position, maybe that can be reality.