• Guillaume Chatelet (4/4) Oct 13 2016 Pretty cool talk by Chandler Carruth on undefined behavior. It
• deadalnix (10/14) Oct 14 2016 I was not very impressed to be honest. His argument is that this
• Guillaume Chatelet (31/45) Oct 16 2016 Well you have to draw the line somewhere and defining it as an
• John Colvin (4/7) Oct 16 2016 Yeah I found that part of the talk interesting but overall

Guillaume Chatelet <chatelet.guillaume gmail.com> writes:

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

deadalnix <deadalnix gmail.com> writes:

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. He rejected plateform defined behavior on 
ground that aren't very solid. That would solve the shift problem 
very nicely.

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.

Guillaume Chatelet <chatelet.guillaume gmail.com> writes:

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

John Colvin <john.loughran.colvin gmail.com> writes:

On Saturday, 15 October 2016 at 00:11:35 UTC, deadalnix wrote:
 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.

Yeah I found that part of the talk interesting but overall 
unconvincing. Just using a local size_t as an index solves the 
problem, no need to modify data structures.