<div dir="ltr"><div dir="ltr">On Wed, Dec 1, 2021 at 5:25 PM Joerg Sonnenberger via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 01, 2021 at 10:57:51PM +0100, Alejandro Colomar (man-pages) via cfe-dev wrote:<br>
> (2):  I'm not sure I understand this one.  I also didn't find the LKML<br>
> thread.  My idea is that if the compiler enforces nonnull-ness as it<br>
> does currently with const, it will be possible to guarantee that sanity<br>
> checks are unnecessary, and therefore they can be safely omitted (by the<br>
> user, not the compiler).<br>
<br>
The original "bug" boils down to something like this:<br>
<br>
   int f(int *p) {<br>
      int x = *p;<br>
      if (!p)<br>
        return -1;<br>
      return x;<br>
   }<br>
<br>
GCC sees the *p, and drops the if condition. Replace that with a call to<br>
a function that has a nonnull attribute and you get the same problem.<br></blockquote><div><br></div><div>I remember vaguely when this was going on, and have multiple times in the past decade wished there was a complete explainer somewhere with all the original links in one place. (If people send me the links, I'll do a blog post with all of them! :))  Here are two links I just googled up, from 2009:</div><div><br></div><div><a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf</a></div><div><br></div><div><a href="https://lwn.net/Articles/341773/">https://lwn.net/Articles/341773/</a></div><div>Warning: the LWN comments contain vastly more heat than light. The top comment gives a great summary of the "correct" side:<br></div><div class="gmail_quote"><br></div>> By looking at the source, this is an obvious coding error - kernel first dereferences a pointer, and after that checks whether it's NULL.</div><div class="gmail_quote"><br></div><div class="gmail_quote">But you'll see that there are also several people arguing on the other side, that this is obviously a compiler bug:</div><div><br></div>> The exploit works because in this case, null is NOT an invalid value, but the compiled code<div>> behaves as though it is (and as though the compiler knows how the dereferencing of an</div><div>> invalid value will be handled ... which it doesn't). So yes, it's a compiler bug.</div><div><br></div><div>(Anyway, this is all just for historical perspectives. Note that in a perfect world, the compiler would warn about "null-check after dereference," and then somehow refrain from optimizing away any null-check unless it had definitely warned about that exact null-check already. Unfortunately, dataflow analysis doesn't work like that in practice.)<br><div><br><div class="gmail_quote">–Arthur</div></div></div></div>