| From: Bill Davidsen <davidsen@xxxxxxx> | 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. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
