Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:
> On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
>> On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
>>>> Which is effectively a type system hole with @disable this :
>>>>
>>>> struct A { @disable this(); }
>>>> auto a = A.init;
>>>
>>> Why this is a type hole if initializer is explicitly provided?
>>>
>>> The idea of disabled this() is to prevent default 
>>> initialization,
>>> not to reject potentially buggy one.
>>
>> Well consider imaginary NotNullable struct that uses "@disable 
>> this()" to guarantee that instance of that struct always has 
>> meaningful state. By using (NotNullable!T).init you can get 
>> value of that type which is in fact null and pass it as an 
>> argument to function that expects NotNullable to always be non 
>> null. With no casts involved you have just circumvented 
>> guarantees static type system was suppose to give.
>
> Hole in the type system: yes
> Necessarily a bad thing: no

It depends on what do you mean by type safety. If commonly 
accepted definition is chosen (for example, what type safety 
article means), than there is no type safety problem here.

> Some data-types require runtime initialisation to be valid. By 
> using .init you are explicitly circumventing any runtime 
> initialisation. It's an explicit hole, just like cast.

Yes, this is known. But note, that it is user, not the language, 
who
circumvents initialization. By the way, what many people expect 
from the feature - to have reference which points to 
preallocated, valid object is hardly achievable in system level 
language where due to free access to memory and memory bugs 
reference may hold any value. For example, class object may turn 
into integer with value 12345.

class A {}
int I = 12345;
A a = cast(A) I;

With the same reasoning I can say that language is faulting here 
because it allowed for me to circumvent my own wishful(!) 
assumption that references should always be allocated and point 
to valid memory.

The fact that pointer or reference can be null, is a tiny, tiny 
problem. You can test for null, but you cannot check whether 
pointer contains valid address. For example, try to figure out 
whether it is safe to write to address 0xFEFFABCD in some 
particular context.

> It appears that it possible (in 2.065 at least) for a struct to 
> provide it's own init, which can of course be
>
> template init() { static assert(false); }
>
> Is the ability to manually specify .init a bug or a feature? I 
> feel like it's a bug.
>

As far as I remember the ability to define init property was 
since 2.058. The semantic would that if you access init 
explicitly, you would get overridden property, but in other cases 
(for example allocation) the semantic is of language init. 
Probably it was filed as a bug, I don't remember.