www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [CBug/Feature Request] Why does the program not crash on a null-pointer

reply J Anderson <REMOVEanderson badmama.com.au> writes:
If I write:

int main (char[][] args)
{
    int *t;
   
    *t; //The program should crash here -access violation

    return 0;
}

The advantages are obvious.  The bug can then be found/fixed much 
earlier before it is ever passed into a function which the user may have 
no control over.

-- 
-Anderson: http://badmama.com.au/~anderson/
Apr 29 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:

 If I write:
 
 int main (char[][] args)
 {
    int *t;
      *t; //The program should crash here -access violation
 
    return 0;
 }
 
 The advantages are obvious.  The bug can then be found/fixed much 
 earlier before it is ever passed into a function which the user may have 
 no control over.
assert(t !== null); achieves what you're after, and is much more self evident. -- andy
Apr 29 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Andy Friesen wrote:

 J Anderson wrote:

 If I write:

 int main (char[][] args)
 {
    int *t;
      *t; //The program should crash here -access violation

    return 0;
 }

 The advantages are obvious.  The bug can then be found/fixed much 
 earlier before it is ever passed into a function which the user may 
 have no control over.
assert(t !== null); achieves what you're after, and is much more self evident. -- andy
I wouldn't want to explicitly place that through every bit of code. int *t; assert(t !== null); func(*t); assert(t !== null); func(*t); assert(t !== null); func(*t); Yuck. Every time you use a pointer you would need an assert on just about every line. This is not what I'm talking about. If you for example dereference a null-pointer (in any situation), then the compiler should cause an access violation message like C++. You could for example be passing t to a function int *t; func(*t); //Access violation It's just obvious. Also this would only be required on debug builds. -- -Anderson: http://badmama.com.au/~anderson/
Apr 29 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6s93o$725$1 digitaldaemon.com...
 If I write:

 int main (char[][] args)
 {
     int *t;

     *t; //The program should crash here -access violation
Isn't that just a null expression? Why should the compiler generate code for that statement? There is no opDeref() in D.
     return 0;
 }

 The advantages are obvious.  The bug can then be found/fixed much
 earlier before it is ever passed into a function which the user may have
 no control over.
Apr 29 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat stlsoft.dot.org> 
wrote:
 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c6s93o$725$1 digitaldaemon.com...
 If I write:

 int main (char[][] args)
 {
     int *t;

     *t; //The program should crash here -access violation
Isn't that just a null expression? Why should the compiler generate code for that statement? There is no opDeref() in D.
Yeah, perhaps you mean: int main (char[][] args) { int *t; int i; i = *t; } or int main (char[][] args) { int *t; *t = 0; } which do indeed generate an "Access Violation"
Apr 29 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr688l9pv5a2sq9 digitalmars.com...
 On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat stlsoft.dot.org>
 wrote:
 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:c6s93o$725$1 digitaldaemon.com...
 If I write:

 int main (char[][] args)
 {
     int *t;

     *t; //The program should crash here -access violation
Isn't that just a null expression? Why should the compiler generate code for that statement? There is no opDeref() in D.
Yeah, perhaps you mean: int main (char[][] args) { int *t; int i; i = *t; } or int main (char[][] args) { int *t; *t = 0; }
Exactly.
 which do indeed generate an "Access Violation"
As we would want, and expect
Apr 29 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr688l9pv5a2sq9 digitalmars.com...
  

On Fri, 30 Apr 2004 14:23:31 +1000, Matthew <matthew.hat stlsoft.dot.org>
wrote:
    

"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c6s93o$725$1 digitaldaemon.com...
      

If I write:

int main (char[][] args)
{
    int *t;

    *t; //The program should crash here -access violation
        
Isn't that just a null expression? Why should the compiler generate code for that statement? There is no opDeref() in D.
Yeah, perhaps you mean: int main (char[][] args) { int *t; int i; i = *t; } or int main (char[][] args) { int *t; *t = 0; }
Exactly.
which do indeed generate an "Access Violation"
    
As we would want, and expect
Sorry, I didn't mean that code exactly. I meant when you dereference a pointer in any case. For example if you dereference when passing to a function you don't get an access violation: int* t; func(*t); //No access violation The reason the code you just gave gives an access violation is not because of the dereference, it's because of the assignment to an no-existent variable. What I'm saying is that the program should cause an access-violation one step earlier, at the dereference. Let's try a slight modification to that example of yours: class A { void t(out int x) { //If I were to do any assignments here there would be a access violation, //but what would happen if this was in a lib? - We wouldn't know where //the error really occured. }; } int main (char[][] args) { A a = new A; int *t; a.t = *t; //No access violation } -- -Anderson: http://badmama.com.au/~anderson/
Apr 30 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
J Anderson wrote:

 Sorry,  I didn't mean that code exactly.  I meant when you dereference 
 a pointer in any case.

 For example if you dereference when passing to a function you don't 
 get an access violation:

 int* t;

 func(*t); //No access violation


 The reason the code you just gave gives an access violation is not 
 because of the dereference, it's because of the assignment to an 
 no-existent variable.  What I'm saying is that the program should 
 cause an access-violation one step earlier, at the dereference.

 Let's try a slight modification to that example of yours:

 class A
 {
    void t(out int x)
    {        //If I were to do any assignments here there would be a 
 access violation,
        //but what would happen if this was in a lib? - We wouldn't 
 know where
        //the error really occured.
    };
   }

 int main (char[][] args)
 {
    A a = new A;

    int *t;
      a.t = *t; //No access violation
 }
Let's take that one step further to prove that that compiler is not optimising this out. class A { void t(out int x) { printf("No access violation\n"); if (&x) x = 5; printf("No access violation\n"); }; } int main (char[][] args) { A a = new A; int *t; a.t = *t; return 0; } -- -Anderson: http://badmama.com.au/~anderson/
Apr 30 2004
parent reply Andy Friesen <andy ikagames.com> writes:
J Anderson wrote:
 
 Let's take that one step further to prove that that compiler is not 
 optimising this out.
 
 class A
 {
    void t(out int x)
    {        printf("No access violation\n");
              if (&x)
            x = 5;
              printf("No access violation\n");
    };
   }
 
 int main (char[][] args)
 {
    A a = new A;
 
    int *t;
      a.t = *t;
 
    return 0;
 }
This is a bit tangental, but using 'out int x' as the argument for a setter is one of the most terrifying misuses of D properties that I have ever seen. (it's also really good evidence that the current property syntax isn't enough) Back on topic, I don't think it's a big deal for the compiler to implicitly assert that a pointer is not null before every dereference while in debug mode. -- andy
Apr 30 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Andy Friesen wrote:

 J Anderson wrote:

 Let's take that one step further to prove that that compiler is not 
 optimising this out.

 class A
 {
    void t(out int x)
    {        printf("No access violation\n");
              if (&x)
            x = 5;
              printf("No access violation\n");
    };
   }

 int main (char[][] args)
 {
    A a = new A;

    int *t;
      a.t = *t;

    return 0;
 }
This is a bit tangental, but using 'out int x' as the argument for a setter is one of the most terrifying misuses of D properties that I have ever seen. (it's also really good evidence that the current property syntax isn't enough) Back on topic, I don't think it's a big deal for the compiler to implicitly assert that a pointer is not null before every dereference while in debug mode. -- andy
Ok is class A { void t(out int x) { printf("No access violation\n"); if (&x) x = 5; printf("No access violation\n"); }; } int main (char[][] args) { A a = new A; int *t; a.t(*t); return 0; } more to your liking. Besides using inout with a setter has it's uses. Imagine passing the object it's parent when calling the setter. I think it is a big deal as it will save many bugs. -- -Anderson: http://badmama.com.au/~anderson/
Apr 30 2004