<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Bruno Wolff III wrote:
<blockquote cite="mid:20090728000959.GA2831@wolff.to" type="cite">
<pre wrap="">On Mon, Jul 27, 2009 at 18:38:03 -0400,
Bill Davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davidsen@tmr.com"><davidsen@tmr.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I don't see a .30 kernel on rawhide, or in updates-testing for FC10, the
</pre>
</blockquote>
<pre wrap=""><!---->
You might have to go back a ways but there were 2.6.30 rawhide kernels.
</pre>
<blockquote type="cite">
<pre wrap="">jump may be waiting on confirmation of this:
<a class="moz-txt-link-freetext" href="http://it.slashdot.org/article.pl?sid=09/07/18/0136224">http://it.slashdot.org/article.pl?sid=09/07/18/0136224</a>
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.
</pre>
</blockquote>
<pre wrap=""><!---->
No gcc isn't broken. Deferencing a null pointer is an undefined operation.
</pre>
</blockquote>
Obviously, but if you read (reread?) the report:<br>
<blockquote>
<pre>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.
</pre>
</blockquote>
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. <br>
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.<br>
<br>
I wouldn't have written it that way at all, putting the initialize in
the definition, but it could be written<br>
<blockquote>struct sock *sk = (tun ? tun->sk : NULL); // initialize
sk with tun->sk<br>
</blockquote>
which would avoid the dereference, but making the code even more
obscure than tunnel code must be.<br>
<br>
<pre class="moz-signature" cols="80">--
Bill Davidsen <a class="moz-txt-link-rfc2396E" href="mailto:davidsen@tmr.com"><davidsen@tmr.com></a>
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.
</pre>
</body>
</html>