public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dmitri Gribenko <gribozavr@gmail.com>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: cfe-dev <cfe-dev@lists.llvm.org>,
	gcc@gcc.gnu.org,  Joseph Myers <joseph@codesourcery.com>
Subject: Re: [cfe-dev] ISO C3X proposal: nonnull qualifier
Date: Tue, 23 Nov 2021 12:32:32 +0100	[thread overview]
Message-ID: <CA+Y5xYePJ-Jn9VipDoxBUnotNvnoAYV-dR7fRZ+=+5xMUJcuiA@mail.gmail.com> (raw)
In-Reply-To: <79b4ef92-38a9-b8ba-6259-f8ade53880ca@gmail.com>

Hi Alejandro,

On Wed, Nov 17, 2021 at 1:06 AM Alejandro Colomar (man-pages) via
cfe-dev <cfe-dev@lists.llvm.org> wrote:
> On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote:
> > $ cat _Nonnull.c
> > #include <stdlib.h>
> >
> > int *_Nonnull f(int *_Nullable p)
> > {
> >      if (!p)
> >          exit(1);
> >      return p;
> > }
> >
> >
> > - I get a warning from f().
> >    Ideally,
> >    a programmer should not need to cast
> >    (casts are dangerous),
> >    to convert a nullable pointer to a _Nonnull pointer.
> >    For that,
> >    appropriate checks should be in the preceeding code.
> >    Otherwise, a diagnostic should be issued.
> >    To be on the safe side,
> >    if a compiler has doubts,
> >    it should diagnose.
> >
> >    There's some Clang document that talks about something similar.
> >    I don't know its validity,
> >    or if it was a draft before _Nonnull qualifiers.
> >    <https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html>
>
> That document suggests that I shouldn't get a diagnostic from f().
> Why did I get a diagnostic?  (I tried clang 11, 13 & 14(experimental))
>
>
> Is it talking about a different nonnull attribute/qualifier?
> Was it about a proposal prior to the current _Nonnull?
> Why is it not in use?  Was it too difficult to implement?

The false positive you're getting is from the Clang warning
-Wnullable-to-nonnull-conversion. It is a simple type-based check that
does not take dataflow information into account. In other words, the
reason for the nullability false positive in your example is identical
to the reason for the integer conversion false positive here:

```
#include <stdlib.h>
#include <stdint.h>
#include <limits.h>

uint8_t f(uint32_t x) {
      if (x > UINT8_MAX)
          exit(1);
     return x;
}
```

warning: implicit conversion loses integer precision: 'uint32_t' (aka
'unsigned int') to 'uint8_t' (aka 'unsigned char')
[-Wimplicit-int-conversion]

This webpage https://clang.llvm.org/docs/analyzer/developer-docs/nullability.html
describes Clang Static Analyzer, is a sophisticated path-sensitive
static analysis tool. It is unfortunately often too slow to enable in
regular compilation.

> Do you think Clang could be improved to not warn on f()?

Absolutely. We can implement a dataflow-based check that takes the
flow condition into account. Flow-sensitive diagnostics should scale a
lot better than path-sensitive, and they should be fast enough to
become a compiler warning. We are currently upstreaming a dataflow
analysis framework that should make implementing such diagnostics
easier. https://lists.llvm.org/pipermail/cfe-dev/2021-October/069098.html

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

  parent reply	other threads:[~2021-11-23 11:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 16:01 Alejandro Colomar (man-pages)
2021-11-15 16:30 ` Alejandro Colomar (man-pages)
2021-11-15 20:18 ` Joseph Myers
2021-11-15 21:09   ` Alejandro Colomar (man-pages)
2021-11-15 22:17     ` Joseph Myers
2021-11-15 22:35       ` Alejandro Colomar (man-pages)
2021-11-15 22:47         ` Joseph Myers
2021-11-16 12:34           ` Alejandro Colomar (man-pages)
2021-11-17  0:06             ` Alejandro Colomar (man-pages)
2021-11-20 16:47               ` Ping: " Alejandro Colomar (man-pages)
2021-11-23 11:32               ` Dmitri Gribenko [this message]
2021-11-23 11:17             ` [cfe-dev] " Dmitri Gribenko
2021-11-23 11:45               ` Alejandro Colomar (man-pages)
2021-11-23 12:45                 ` Dmitri Gribenko
2021-12-01 22:24                   ` Alejandro Colomar (man-pages)
2021-12-02  0:39                     ` Dmitri Gribenko
2021-12-02  1:00                       ` Alejandro Colomar (man-pages)
2021-12-02 20:24             ` Alejandro Colomar (man-pages)
2021-12-02 20:31               ` Alejandro Colomar (man-pages)
2021-12-02 20:36               ` Joseph Myers
2021-11-16  9:30     ` Jonathan Wakely
2021-11-16 17:13       ` [cfe-dev] " Arthur O'Dwyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+Y5xYePJ-Jn9VipDoxBUnotNvnoAYV-dR7fRZ+=+5xMUJcuiA@mail.gmail.com' \
    --to=gribozavr@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=cfe-dev@lists.llvm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).