D - Unsafe and doomed

[Michel Fortin]

On 2014-01-06 21:09:44 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 1/6/2014 1:03 PM, Walter Bright wrote:
>> On 1/6/2014 11:21 AM, deadalnix wrote:
>>> Or, we can decide that trapping in not guaranteed, and then dereferencing null
>>> is undefined behavior,
>>> which is much worse that a compile time failure.
>> 
>> Realistically, this is a non-problem.
> 
> Or better, if you want to issue a pull request for the documentation 
> that says unless it is a dead load, a null reference will cause a 
> program-ending fault of one sort or another, I'll back it.

That's pretty much the same as undefined behaviour because "dead load" 
is not defined. What is a dead load actually depends on how much 
inlining is done and how the optimizer works, and that's hard to define 
as part of the language.

For instance, you could dereference a value and pass it to a function 
(as in "foo(*x)"). If that function gets inlined, and if what that 
function does is it multiplies the passed integer by zero, then the 
optimizer might rewrite the program to never load the value, the null 
dereference has simply disappeared.

I think the best way to describe what happens is this: The only 
guaranty made when dereferencing a null pointer is that the program 
will stop instead of using a garbage value. An optimizing compiler 
might find ways to avoid or delay using dereferenced values which will 
allow the program to continue running beyond the null dereference. In 
general one shouldn't count on dereferencing a null pointer to stop a 
program at the right place or at all.

I think this is a good explanation of what happens, but it obviously 
leaves undefined the *if and when* it'll stop the program because this 
highly depends on inlining and what the optimizer does.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca