Hacker News Reader

Comment by mike_hock | Hacker News Reader

Once it's complete, make it authoritative. Any mention of undefined behavior should be required to reference the corresponding item in the UB annex.

View on HN

The hard part of UB isn't where it's mentioned in the standard. The problem is when the standard says "in case A, X occurs, in case B, Y occurs" then somebody invents a situation where neither A nor B apply.

And even better, start reducing the list after it's complete, by pushing things like integer overflow into implementation defined; several uses of inc/decrement operators into compilation error; and etc.

I don't want integer overflow to be implementation defined though, I want it undefined so my compiler can optimize my code for the fact that I don't overflow my integers in the first place.

The implementation can define the behavior on overflow to be the optimized behavior. Optimization and UB are orthogonal concepts.

Implementation defined is not much better than undefined. It only requires documenting the behavior, so compilers could just go like "here are all the optimizations that we apply on each target platform for each set of compiler flags". It's not very helpful, you might as well look at the source code of the compiler.

That's still substantially better than undefined, where multiple runs of the same compiler version on the same source with the same settings are allowed to result in different behaviors. I suppose an implementation could define non-deterministic behavior, but that's unlikely and could be forbidden by the standard.

That said, my overall point is that optimization does not rely on undefined behavior at all. It's commonly argued that it does, but there are languages without undefined behavior that have working optimizers, so it's clearly false. Some optimizations for C (and C++) currently depend on undefined behavior, but there's nothing inherent about that dependence.

Reply on news.ycombinator.com