From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by sourceware.org (Postfix) with ESMTPS id 9213B3858D28 for ; Tue, 23 Nov 2021 11:32:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9213B3858D28 Received: by mail-yb1-xb34.google.com with SMTP id v7so58857219ybq.0 for ; Tue, 23 Nov 2021 03:32:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yt3GUsA9sLRwiCdqhDuV88Iv+i03XIuBva4ptQ4qpCE=; b=xLmoRowychHqEjDTtP8UyzY36DwEbp7fez85AyCHcqd8R2KA7eqEBEttMRiZPMn2Ek MmQdnr82JSdVY0UwXHeKG3D1MhyflDM8lp1x9Rgae0kAAbkLgNsdyVwF7YhX66PfekIL y4LT7MbOdFV3iT33eOlQq8XAYKCFcgXQiAT/mFmdISoh2Xp50O4rVTtm59d40l/wJwIJ LM8gAAa+BgYCE4lrZPXZbzv0/ktuDYoiaBzPZkCCnW5AfSzd61QP0F4diCu2T1m65zHJ FoSzGIvx/9PtpNbPGu89HmPnmmB2aPpYs94sgVapBRKU+xIYhIcB79TBmOnVc/MXOYga BN3g== X-Gm-Message-State: AOAM532XoUs1p170hquqhVk1X5O1iKIzCDigoQSuJgCRemCeYqYPVBVJ P0fQ+GVdLrI+D7+VEAlStcUHWGz6rXeDToXMVO0= X-Google-Smtp-Source: ABdhPJwWpgcN7U6jYXKlbUW39BEopzZjzfh5uywwdXt/kTwxG8M1bnVkng9Ce8sms+MXINSKyeuzSlG4aKMrcAQWNNM= X-Received: by 2002:a25:b94b:: with SMTP id s11mr5256927ybm.518.1637667178164; Tue, 23 Nov 2021 03:32:58 -0800 (PST) MIME-Version: 1.0 References: <56a1a945-608e-0e5e-7610-c35481abb980@gmail.com> <4883fa8c-2d99-2611-a8e2-6c7612283da4@gmail.com> <79b4ef92-38a9-b8ba-6259-f8ade53880ca@gmail.com> In-Reply-To: <79b4ef92-38a9-b8ba-6259-f8ade53880ca@gmail.com> From: Dmitri Gribenko Date: Tue, 23 Nov 2021 12:32:32 +0100 Message-ID: Subject: Re: [cfe-dev] ISO C3X proposal: nonnull qualifier To: "Alejandro Colomar (man-pages)" Cc: cfe-dev , gcc@gcc.gnu.org, Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 11:33:00 -0000 Hi Alejandro, On Wed, Nov 17, 2021 at 1:06 AM Alejandro Colomar (man-pages) via cfe-dev wrote: > On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote: > > $ cat _Nonnull.c > > #include > > > > 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. > > > > 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 #include #include 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*/