Hi! > "Jean Delvare" <[EMAIL PROTECTED]> said: > > > > > No, there is a third case: the pointer can be NULL, but the compiler > > > > > happened to move the dereference down to after the check. > > > > > Wow. Great point. I completely missed that possibility. In fact I didn't > > > > know that the compiler could possibly alter the order of the > > > > instructions. For one thing, I thought it was simply not allowed to. For > > > > another, I didn't know that it had been made so aware that it could > > > > actually figure out how to do this kind of things. What a mess. Let's > > > > just hope that the gcc folks know their business :) > > > > The compiler is most definitely /not/ allowed to change the results the > > > code gives. > > > I think that Andrew's point was that the compiler could change the order > > of the instructions *when this doesn't change the result*, not just in > > the general case, of course. In our example, The instructions: > > > > v = p->field; > > if (!p) return; > > > > can be seen as equivalent to > > > > if (!p) return; > > v = p->field; > > They are not. If p == NULL, the first gives an exception (SIGSEGV), the > second one doesn't. Just as you can't "optimize" by switching: > > x = b / a; > if (a == 0) return;
Dereferencing NULL pointer is undefined. It *may* give SIGSEGV. That's what enables optimization above. You can't rely on dereferencing NULL to always give SIGSEGV. Sorry. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/