proposed patch for gcse.c (delete_null_pointer_checks)

Thomas R. Truscott trt@cs.duke.edu
Thu Oct 28 08:45:00 GMT 1999


>   > This patch also deduces this for small offsets such as "p[1]".
> I'm not sure that is a wise thing to do.  Dereferencing a null
> pointer is an absolute naughty thing to do according to ANSI/ISO.
> No other pointer value has that property that I'm aware of.

The draft C9X lists additional "invalid values for dereferencing",
and indicates there may be additional implementation-defined ones.
It also says "Such a pointer, called a null pointer, is guaranteed
to compare unequal to a pointer to any object or function."
I believe it is reasonable to infer that dereferencing a
null pointer "p" is invalid whether done with p[0] or p[1] or p->x
since none of these can be an object or function.

For normal ("user mode") programs on most current operating systems,
anything near location 0 is strictly off limits.
(Some systems such as AIX do not prevent access to low memory,
and the compiler may even exploit that for performance,
but explicit references by the program to low memory remain invalid.)


> We had a customer that created a structure that was the size of
> the physical memory on his target, then used a pointer to that
> structure to twiddle any memory location they wanted.

For this to work properly the current delete-null-pointer-checks
must also be disabled, otherwise a de-reference of location zero
would cause gcc to erroneously deduce that the pointer was non-null.
Of course this would only cause a bug if the program
then tested the pointer to see if it was NULL.
But if this of any concern to you,
then the current delete-null-pointer-checks should off by default.


> I'm not planning to install the code to handle small offsets --
> unless someone can convince me that it's a reasonable thing to do.

The patch triples (or better) the effectiveness of the optimization
and I think it would be unfortunate to miss that benefit.
I do not think there exists any real C code, even in "kernel" mode,
which would actually break due the proposed patch.
But again, if this is of any concern to you
please have the optimization off by default.

Tom Truscott


More information about the Gcc-patches mailing list