Disallow null references in safe code?

[deadalnix]

On Sunday, 2 February 2014 at 03:27:21 UTC, Andrei Alexandrescu 
wrote:
> On 2/1/14, 5:17 PM, deadalnix wrote:
>> On Sunday, 2 February 2014 at 01:01:25 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 2/1/14, 1:40 PM, deadalnix wrote:
>>>> On Saturday, 1 February 2014 at 20:09:13 UTC, Andrei 
>>>> Alexandrescu wrote:
>>>>> This has been discussed to death a number of times. A field 
>>>>> access
>>>>> obj.field will use addressing with a constant offset. If 
>>>>> that offset
>>>>> is larger than the lowest address allowed to the 
>>>>> application, unsafety
>>>>> may occur.
>>>>>
>>>>
>>>> That is one point. The other point is that the optimizer can 
>>>> remove a
>>>> null check, and then a load, causing undefined behavior.
>>>
>>> I don't understand this. Program crash is defined behavior.
>>>
>>> Andrei
>>
>> This has also been discussed. Let's consider the buggy code 
>> bellow:
>>
>> void foo(int* ptr) {
>>   *ptr;
>>   if (ptr !is null) {
>>     // do stuff
>>   }
>>
>>   // do other stuff
>> }
>>
>> Note that the code presented above look quite stupid, but this 
>> is
>> typically what you end up with if you call 2 function, one 
>> that does a
>> null check and one that doesn't after inlining.
>>
>> You would expect that the program segfault at the first line. 
>> But it is
>> in fact undefined behavior. The optimizer can decide to remove 
>> the null
>> check as ptr is dereferenced before so can't be null, and a 
>> later pass
>> can remove the first deference as it is a dead load. Both GCC 
>> and LLVM
>> optimizer can exhibit such behavior.
>
> Do you have any pointers to substantiate that? I find such a 
> behavior rather bizarre.
>
> Andrei

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html