Linux "NULL pointer dereferece" in the News...

[Joel Rees]

(Sorry about hashing the threading.)
Tom Horsley commented,
> On Sun, 19 Jul 2009 11:49:42 -0700
> Michael Eager wrote,
>
> > OK, write a description of how to determine one case from the
> > other and I'm sure every compiler developer will rush to  
> implement it.
>
> The fact that they already have a -fno-delete-null-pointer-checks  
> option
> in the compiler seems to demonstrate that they know they are doing
> this specifically because it is undefined and they can do whatever
> they want (including checking a compiler option to choose a different
> thing to do). I guess thinking that the best choice is always
> to do what the source code says makes me a member of a looney
> minority though :-).


Well, the -fno-delete-null-pointer-checks option was intended for a  
related, but different class of problems, specifically certain  
application areas where it is defined to access NULL pointers. (The  
standard does not define the behavior, but it isn't really against  
the standard for a specific application field to define the behavior.  
The code becomes non-standard C, however.)

(Specifically, embedded applications, although I tend to wonder if  
the hardware design could not usually get around the reasons for  
putting valid stuff in the bottom of memory. Actually, I'm beginning  
to wonder, what with modern logical address spaces usually  
significantly larger than applications need, whether it doesn't make  
sense to devote address bits to the problems of classifying pointers.)

The C standard does not specify that every function returning a  
pointer return invalid pointers. Moreover, it does not specify how to  
determine a valid pointer, even though we customarily assume the NULL  
pointer idiom.

I don't disagree that it feels awkward that they know the pointer has  
been referenced and therefore would seem to be valid, thus, non-NULL,  
but aren't able to back up the parse stack and see that the access  
looks like a test-after-use bug.

Also, we humans walk back up parse stacks with relative ease, but it  
slows compilers down to be walking back up the parse stack with  
assumed valid code. I'm talking, worst case could be slow enough to  
be completely unusable.