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

Bruno Wolff III wrote:

On Mon, Jul 27, 2009 at 18:38:03 -0400,
  Bill Davidsen <davidsen@xxxxxxx> wrote:

I don't see a .30 kernel on rawhide, or in updates-testing for FC10, the


You might have to go back a ways but there were 2.6.30 rawhide kernels.

jump may be waiting on confirmation of this:
  http://it.slashdot.org/article.pl?sid=09/07/18/0136224
although GCC would seem broken if it really generates the code claimed,  
initializing a variable does not prevent it from being NULL. I'm unsere 
if this is a problem, but it might be held back until checked.


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.

The claim is that the test is optimized away, and that would seem to be a separate issue from using the value of tun before testing.
Note that I was pointing out the report, not making any claims that it was correct. That's what the "until checked" in my post meant, someone should verify that the compiler doesn't have a bug separate from the dereference.

I wouldn't have written it that way at all, putting the initialize in the definition, but it could be written

struct sock *sk = (tun ? tun->sk : NULL); // initialize sk with tun->sk

which would avoid the dereference, but making the code even more obscure than tunnel code must be.

-- 
Bill Davidsen <davidsen@xxxxxxx>
  Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one error occurs during
wildcard (glob) expansion.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines