Re: Null pointer dereference and side effects

[Archie Cobbs <archie at dellroad dot org>]

Eljay Love-Jensen wrote:
> Try this...
> 
>      #include <stdlib.h>
> 
>      int dummy;
> 
>      int
>      main(int ac, char **av)
>      {
> 	    int *r1;
> 	    int *r2;
> 
> 	    r1 = &ac;
> 	    *r1 = 0;
> 	    r2 = (void *)0;	/* or (void *)1, etc. */
>                 dummy = *r1; /* k-boom */
> 	    if (*r1 != *r2)
> 		    return 1;
> 	    return 1;
>      }

Doesn't segfault..

> --or this--
> 
>      #include <stdlib.h>
> 
>      int
>      main(int ac, char **av)
>      {
> 	    volatile int *r1;
> 	    volatile int *r2;
> 
> 	    r1 = &ac;
> 	    *r1 = 0;
> 	    r2 = (void *)0;	/* or (void *)1, etc. */
> 	    if (*r1 != *r2)
> 		    return 1;
> 	    return 1;
>      }

Does segfault..

I should have stated that this C code is being machine generated, so what
I'd really like to know is exactly what to expect from the compiler
so I can adjust the code-generating algorithm appropriately to avoid
such situations. That is, I need to be able to guarantee that null
pointer dereferences don't get optimized away.

One way to do this is using "volatile"...

This all makes me curious about what the compiler's stance is with respect
to side effects. E.g., in the docs for "-fdelete-null-pointer-checks"
it says "The compiler assumes that dereferencing a null pointer would
have halted the program".

But my test program seems to contradict this statement that the compiler 
is always aware and respectful of these side effects.

I'm curious if there is some documentation describing exactly what
to expect in this situation.. ?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com