[cfe-dev] ISO C3X proposal: nonnull qualifier

[Arthur O'Dwyer via cfe-dev]

On Wed, Dec 1, 2021 at 5:25 PM Joerg Sonnenberger via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, Dec 01, 2021 at 10:57:51PM +0100, Alejandro Colomar (man-pages)
> via cfe-dev wrote:
> > (2):  I'm not sure I understand this one.  I also didn't find the LKML
> > thread.  My idea is that if the compiler enforces nonnull-ness as it
> > does currently with const, it will be possible to guarantee that sanity
> > checks are unnecessary, and therefore they can be safely omitted (by the
> > user, not the compiler).
>
> The original "bug" boils down to something like this:
>
>    int f(int *p) {
>       int x = *p;
>       if (!p)
>         return -1;
>       return x;
>    }
>
> GCC sees the *p, and drops the if condition. Replace that with a call to
> a function that has a nonnull attribute and you get the same problem.
>

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:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf

https://lwn.net/Articles/341773/
Warning: the LWN comments contain vastly more heat than light. The top
comment gives a great summary of the "correct" side:

> By looking at the source, this is an obvious coding error - kernel first
dereferences a pointer, and after that checks whether it's NULL.

But you'll see that there are also several people arguing on the other
side, that this is obviously a compiler bug:

> The exploit works because in this case, null is NOT an invalid value, but
the compiled code
> behaves as though it is (and as though the compiler knows how the
dereferencing of an
> invalid value will be handled ... which it doesn't). So yes, it's a
compiler bug.

(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.)

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211201/73ba6c7d/attachment.html>