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."
