Null pointer dereferencing in D

[Wanderer via Digitalmars-d]

On Friday, 13 June 2014 at 21:13:20 UTC, bearophile wrote:
> This was surely discussed in past, but I don't remember the 
> answer (so perhaps this is more fit in D.learn).
>
> Dereferencing the null pointer in C is undefined behaviour, so 
> in most cases the program segfaults, but sometimes the compiler 
> assumes a dereferenced pointer can't be null, so it optimizes 
> away tests and other parts, leading to bugs and problems, 
> including exploits:
>
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
>
> What's the solution for very optimizing D compilers like GDC, 
> now and in future? Surely the C not-solution is not acceptable 
> in a safe language as D.
>
> Perhaps D can define dereferencing the null pointer in C as 
> segfaulting in all cases. Is this acceptable for people that 
> could desire to write a kernel in D?
>
> An alternative possibility is to go the Java way, and add a 
> compiler switch that adds an assert before every pointer 
> dereference after the compiler has optimized the code (and 
> remove some of such asserts where the compiler is certain they 
> can't be null).
>
> What's the solution used by Rust (beside not having to deal 
> with nulls in many cases)?
>
> Bye,
> bearophile

Since you mentioned Java, NPE (NullPointerException) that throws 
every time null gets defererenced, is a real plaque of the 
language, hard to spot, hard to debug etc. So even without 
segfaults or exploits, nulls are PITA there and many programmers 
just refrain from using null values at all, explicitly 
initializing all references in 100% cases and marking all usages 
as @NotNull.

Maybe, if D decides to encourage programmers to use similar 
technique, it would be possible to optimize away most of such 
runtime checks and keep the language both fast *and* safe.