null dereference exception vs. segfault?

[Jeffrey Yasskin]

On Mon, Aug 2, 2010 at 1:49 AM, Jonathan M Davis <jmdavisprog at gmail.com> wrote:
> On Monday 02 August 2010 00:05:40 Jeffrey Yasskin wrote:
>> Even better, you can annotate fail_sometimes with @safe, and it'll
>> still access out-of-bounds memory.
>>
>> Take the following with a grain of salt since I'm really new to the
>> language.
>>
>> gdb says:
>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000008
>> 0x00001e52 in D4test14fail_sometimesFiZv ()
>>
>> which indicates that 'a' is getting initialized to null (possibly by
>> process startup 0ing out the stack), and then x is being read out of
>> it. You can get exactly the same crashes in C++ by reading member
>> variables out of null pointers. The D compiler is supposed to catch
>> the uninitialized variable ("It is an error to use a local variable
>> without first assigning it a value." in
>> http://www.digitalmars.com/d/2.0/function.html), but clearly it's
>> missing this one.
>>
>> I haven't actually found where in the language spec it says that class
>> variables are pointers, or what their default values are. I'd expect
>> to find this in http://www.digitalmars.com/d/2.0/type.html, but no
>> luck.
>>
>> Looking through the bug tracker ... Walter's response to
>> http://d.puremagic.com/issues/show_bug.cgi?id=671 seems to indicate
>> that he isn't serious about uninitialized use being an error. It's
>> just undefined behavior like in C++.
>>
>> In any case, the fix for your problem will be to initialize 'a' before
>> using it.
>
> _All_ variables in D are initialized with a default value. There should be _no_
> undefined behavior with regards to initializations. D is very concientious about
> avoiding undefined behavior. In the case of references and pointers, they are
> initialized to null.

That's good to know. Unfortunately, reading through a null pointer
does cause undefined behavior: it's not a guaranteed segfault.
Consider an object with a large array at the beginning, which pushes
later members past the empty pages at the beginning of the address
space. I don't suppose the D compiler watches for such large objects
and emits actual null checks before indexing into them?

> The pages that you're looking at there need to be updated for clarity.

Nice use of the passive voice. Who needs to update them? Is their
source somewhere you or I could send a patch?