On Saturday, 15 October 2016 at 00:11:35 UTC, deadalnix wrote:
On Thursday, 13 October 2016 at 15:19:17 UTC, Guillaume Chatelet wrote:
Pretty cool talk by Chandler Carruth on undefined behavior. It reminds me of a bunch of conversations than happened on this mailing list. I bet Walter will like it :)


https://www.youtube.com/watch?v=yG1OZ69H_-o

I was not very impressed to be honest. His argument is that this is an error, but really this isn't or people wouldn't be that mad at undefined behavior.

Well you have to draw the line somewhere and defining it as an error makes sense to me. I think people are mad because they code something reasonable but it's UB. It's like being a good citizen and receiving a fine because a speed limit sign was hidden by a tree. It's hard not to be angry then. If your compiler could always point you at the error, you'd be much less angry because you'd be aware of the rule early. It may still be a stupid rule but at least you'd know. Unfortunately it's hard if not impossible to detect them.

Some of them [1] are mitigated in D: Uninitialized scalar, Access out of bounds. But basic type computation UB are pervasive and exposed to the user directly. The difficulty comes from the impedance mismatch between the language semantics and the available hardware.

That would solve the shift problem very nicely.

As Chandler mentioned at the end of the talk, there are no real rationale for some of the UB and it would totally make sense to have them defined now.


His argument about indices was also weak as it tells more about the need to use size_t rather than 32 bits indices when doing indices computation.

Isn't size_t just an alias to unsigned int? Does the compiler treat it in a special way which would remove the need for overflow detection?


1. See http://en.cppreference.com/w/cpp/language/ub
"undefined behavior - there are no restrictions on the behavior of the program. Examples of undefined behavior are memory accesses outside of array bounds, signed integer overflow, null pointer dereference, modification of the same scalar more than once in an expression without sequence points, access to an object through a pointer of a different type, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful."

Reply via email to