www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How does D handle null pointers?

reply Adam B <cruxic gmail.com> writes:
Hello all,

Yesterday I started playing with D for the first time, (I'm a Java &
C++ programmer by day and a python programmer by night).  In my first
experiments I wanted to prove that:

=A0 1) Exceptions have stack traces (so you can tell *where* the error occu=
rred!)
=A0 2) Indexing into an array causes an exception instead of a segfault
or memory corruption
=A0 3) Dereferencing null pointers causes an exception instead of a segfaul=
t

D 2.0 seems to handle my first two tests just fine but this program
causes a segfault:

------------
class A
{
    int i;
}

int main(char[][] args)
{
    A a =3D null;
    a.i++;
    return 0;
}
------------

I realize that checking every pointer dereference is expensive but, in
my experience, null pointer dereferences are one of the top 5 runtime
errors.  At work I troubleshoot java NullPointerExceptions on a weekly
basis.  Can you imagine trying to troubleshoot a massive web
application that crashes with the phrase "Segmentation Fault" after
running just fine for two weeks?  Without a stack trace it's not
reasonable.

Does D address this problem?  Perhaps another compiler switch similar
to the existing -noboundscheck ?

Cheers
- Adam B
Aug 20 2010
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Adam B (cruxic gmail.com)'s article
 Hello all,
 Yesterday I started playing with D for the first time, (I'm a Java &
 C++ programmer by day and a python programmer by night).  In my first
 experiments I wanted to prove that:
   1) Exceptions have stack traces (so you can tell *where* the error occu
 rred!)
   2) Indexing into an array causes an exception instead of a segfault
 or memory corruption
   3) Dereferencing null pointers causes an exception instead of a segfaul
 t
 D 2.0 seems to handle my first two tests just fine but this program
 causes a segfault:
 ------------
 class A
 {
     int i;
 }
 int main(char[][] args)
 {
     A a = null;
     a.i++;
     return 0;
 }
 ------------
 I realize that checking every pointer dereference is expensive but, in
 my experience, null pointer dereferences are one of the top 5 runtime
 errors.  At work I troubleshoot java NullPointerExceptions on a weekly
 basis.  Can you imagine trying to troubleshoot a massive web
 application that crashes with the phrase "Segmentation Fault" after
 running just fine for two weeks?  Without a stack trace it's not
 reasonable.
 Does D address this problem?  Perhaps another compiler switch similar
 to the existing -noboundscheck ?
 Cheers
 - Adam B

Currently null pointer dereferences do just segfault your program. IMHO this needs to be fixed eventually. I'd love to see something analogous to array bounds checking where null pointers are checked for in debug mode and these checks are turned off in release mode.
Aug 20 2010
prev sibling parent Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Adam B wrote:

 Hello all,
 
 Yesterday I started playing with D for the first time, (I'm a Java &
 C++ programmer by day and a python programmer by night).  In my first
 experiments I wanted to prove that:
 
 1) Exceptions have stack traces (so you can tell *where* the error
 occurred!) 2) Indexing into an array causes an exception instead of a
 segfault or memory corruption
 3) Dereferencing null pointers causes an exception instead of a segfault
 
 D 2.0 seems to handle my first two tests just fine but this program
 causes a segfault:
 
 ------------
 class A
 {
     int i;
 }
 
 int main(char[][] args)
 {
     A a = null;
     a.i++;
     return 0;
 }
 ------------
 
 I realize that checking every pointer dereference is expensive but, in
 my experience, null pointer dereferences are one of the top 5 runtime
 errors.  At work I troubleshoot java NullPointerExceptions on a weekly
 basis.  Can you imagine trying to troubleshoot a massive web
 application that crashes with the phrase "Segmentation Fault" after
 running just fine for two weeks?  Without a stack trace it's not
 reasonable.
 
 Does D address this problem?  Perhaps another compiler switch similar
 to the existing -noboundscheck ?
 
 Cheers
 - Adam B

The only way I currently have checking for nullpointer accesses for classes is by using a auto implement of the specific class with a invariant that asserts. But it doesn't protect against a latter assign of null. Perhaps overriding opAssign in the auto implemented class would protect against that. If that is the case then you would have to initialize instances using something like: A a = nonnull!A;
Aug 22 2010