Disallow null references in safe code?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sat Feb 1 19:27:00 PST 2014


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




More information about the Digitalmars-d mailing list