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

Re: Status of a 2.6.30 kernel ? Other sources for a 2.6.30 kernel.



| From: Bill Davidsen <davidsen tmr com>

| Bruno Wolff III wrote:

| > No gcc isn't broken. Deferencing a null pointer is an undefined operation.

| Obviously, but if you read (reread?) the report:
| 
|    if (!tun)
|        return POLLERR;  // if tun is NULL return error
| 
|    This code looks perfectly ok, right? Well, it is, until the compiler
|    takes this into its hands. While optimizing the code, the compiler will
|    see that the variable has already been assigned and will actually
|    remove the if block (the check if tun is NULL) completely from the
|    resulting compiled code.

This explanation is wrong.

Dereferencing a NULL pointer is undefined.

On most reasonable implementations, it causes a crash[1].  In Linux
userland, it causes a SEGV, at least on most architectures.  I'm
pretty sure that it used to cause an "oops" in Kernel code.

Such systems are a concrete example of where the optimization is a
Good Thing: code size is reduced and yet no execution flow would be
changed.

On other systems, the optimization is correct.  That is because the
program is already in error by the time the optimization would lead to
a different result.

Another way of thinking of this is to realize that dereferencing a
pointer is tantamount to asserting that it is not null.

What I don't understand is why the kernel isn't oopsing on the
dereferencing of null.  (I'm not a kernel hacker, so the fact that this
surprises me probably says more about me than the kernel.)


[1]

Crashing on null dereference is really very useful for C programmers
wishing to debug their code.  In fact, the more language violations
that are detected, the better.

Not all C implementations crash on null dereference.  If I remember
correctly, I first experienced this great feature on UNIX on a VAX;
the PDP-11 had very little address space (64k!) so the C
implementation could not afford to reserve a page to cause this crash.

I liked this feature so much that we implemented it on the first
UNIX box I owned.  It took a hardware change!  And, of course, several
software changes.


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