[Semi OT] - "Garbage In, Garbage Out: Arguing about Undefined Behavior..."

[Guillaume Chatelet via Digitalmars-d]

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