DIP 1006 - Preliminary Review Round 1
ag0aep6g
anonymous at example.com
Mon Mar 5 23:52:50 UTC 2018
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?
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. 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?
More information about the Digitalmars-d
mailing list