From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 09C54385841A for ; Thu, 2 Dec 2021 20:24:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09C54385841A Received: by mail-wm1-x336.google.com with SMTP id p18so688738wmq.5 for ; Thu, 02 Dec 2021 12:24:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=6DnQIo8hWw6yRetx/e7FhxzkJDlimw0ejix6J1yxTFA=; b=re4P/FNBi+URIU5puDkzNDD+db42KqgPwNrove9mzknZaIq/uASSkgIqoF0N0j/C2r nPjr3QTiec1+KP+9OaBYr01D5yDHNllLiixDU0nOxUgOljLKLTtlu5SeaN5eUV8t00yr kdh0Byn1akgYTmiHVCIEoWsAFlyTaEoF5hVcea+gZOSAhq+alPzOsbj86lYgQbIwejN8 2JOwFqfvWZ8KntVfrreK+L1Agr5XnMIzfgCHDjs/7f5ZhZc8gfuDGqDqhPVxKJDWTvOo f/JMeIJ+YFoYVMypPNwr0LX94kF6iOMnoNAYlU/IU2L8tJk4hPDArv7Lgd4QWNnkCruf xGwA== X-Gm-Message-State: AOAM533IE/V9rrVznvYYYW3yq/Tiol5jLEacLKu8qLwSVTSNEOZTU0p/ thAtXW/Pwqv0t2nj/H54X0E= X-Google-Smtp-Source: ABdhPJx/LveTVy32i+Mta2gilqHQDmfR1oKja/n8IY0+Jn592DK1rP9JwXHUIvuwOeF77sqYR2ePOQ== X-Received: by 2002:a1c:9d13:: with SMTP id g19mr9155077wme.41.1638476676022; Thu, 02 Dec 2021 12:24:36 -0800 (PST) Received: from [10.168.10.170] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id t127sm3169284wma.9.2021.12.02.12.24.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 12:24:35 -0800 (PST) Sender: Alejandro Colomar Message-ID: <3178a917-e9df-36eb-4382-f8aec7b678a2@gmail.com> Date: Thu, 2 Dec 2021 21:24:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: ISO C3X proposal: nonnull qualifier Content-Language: en-US From: "Alejandro Colomar (man-pages)" To: Joseph Myers Cc: gcc@gcc.gnu.org, cfe-dev@lists.llvm.org References: <56a1a945-608e-0e5e-7610-c35481abb980@gmail.com> <4883fa8c-2d99-2611-a8e2-6c7612283da4@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Thu, 02 Dec 2021 20:24:39 -0000 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; > } > > int *_Nonnull g(int *_Null_unspecified p) > { >     return p; > } > > int *_Nonnull h(int *p) > { >     return p; > } > > int *_Nullable i(int *_Nonnull p) > { >     return p; > } > > --- > I see other problems: > > - I don't get a warning from g(), nor from h(), which I'd want. >   To get something like const-safety, >   we need to design it so that it can be enforced; >   either you guarantee that a pointer cannot be NULL (_Nonnull), >   or you cannot guarantee it (not _Nonnull). >   Otherwise, >   [[gnu::nonnull]] would seem better to me. > >   So, I'd leave out of the design everything but _Nonnull, >   and consider everything else as nullable by default. Getting warnings from h() and g() would be easy to impose. Just forbid implicit addition of _Nonnull qualifier. > > - 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. >   I came with an idea that would make this QoI, so that the ISO standard wouldn't need to force every compiler to be flow-sensitive, which would be a bad precedent. Implicit additions of the qualifier could be allowed to be warned _always_ by the standard. As an extension, quality compilers may not warn when they can see a NULL check just before the assignment. User code could make of the following macro, to avoid having to add casts everywhere, which would be as bad as not having _Nonnull at all. I got the idea from the GCC __builtin_xxx_overflow() builtins. #if defined(__cplusplus) #define const_cast(t, x) const_cast(x) #else #define const_cast(t, x) ((t) (x)) #endif #if !defined(cplusplus) #define auto __auto_type #endif #define nonnull_assign(nn, p) \ ({ \ auto p_ = p; \ auto nn_ = nn; \ \ if (p_ == NULL) \ *nn_ = const_cast(typeof(nn_), p_); \ \ p_ == NULL; \ }) And use it like this: int *_Nonnull f(int *_Nullable p) { int *_Nonnull q; if (nonnull_assign(&q, p)) exit(1); return q; } That way there's only one place where there's a cast, so it can be easily audited. The above would be warning-free, without requiring a lot of complexity into the compiler. Please, forgive the extensive use of GNU extensions in the above snippet (and the redefinition of auto), as I forgive those who don't use them :) So, now this can be made non-flow-sensitive, which was a big concern. And now the biggest concern I can see is that this qualifier works opposite to const (here discarding is allowed but not adding it), and that is contrary to how compilers have been working for now. As far as I could read in the standard, there's no mention to qualifiers being dropped in an rvalue; Joseph, could you please confirm? Also, as I already mentioned, Clang already implements this somehow without discarding the _Nonnull qualifier, so I guess this can be done. Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/