[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



(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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]