DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

On 06.03.2018 00:52, ag0aep6g wrote:
> On 03/05/2018 11:57 PM, Timon Gehr wrote:
>> On 05.03.2018 22:24, ag0aep6g wrote:
>>> On 03/05/2018 10:11 PM, Walter Bright wrote:
> [...]
>>>> It is not defined behavior with -boundscheck=off.
>>>
>>> Dereferencing null is not defined with -boundscheck=off?
>>
>> This was my bad. It's not dereferencing null. The compiler is free to 
>> assume 0<x.length, which means it is allowed to think that the main 
>> function is dead code.
> 
> How is it free to assume that?
> ...

By Walter's definition. -boundscheck=off makes the compiler assume that 
all array accesses are within bounds. ("off" is a misleading term.)

> This was the full snippet (before I mutilated it in my quote):
> 
> ----
> void main()@safe{
>       int[] x=[];
>       writeln(x[0]); // range violation even with -release
>                      // defined behavior even with -boundscheck=off (!)
> }
> ----
> 
> There is no `assert(0<x.length);` in this one. -release doesn't do 
> anything, because there are no contracts, no asserts, and main is @safe. 
> -boundscheck=off just makes it so that the length isn't checked before 
> x.ptr is dereferenced.

It's not checked, but the compiler may still assume that it has actually 
been checked. The story is similar to asserts.

> x.ptr is null, so the code is defined to 
> dereference null, no?
> 
> If -boundscheck=off somehow does introduce UB here, we have the weird 
> situation that using `x.ptr[0]` is more safe than in this scenario than 
> `x[0]`. Because surely `x.ptr[0]` is a null dereference that's not 
> affected by -boundscheck=off, right?

Yes, I think that's a good point (though it hinges on the assumption 
that x.ptr[i] is equivalent to *(x.ptr+i), which I'm not sure the 
specification states explicitly).