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