From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xmailer.gwdg.de (xmailer.gwdg.de [134.76.10.29]) by sourceware.org (Postfix) with ESMTPS id 42AC23858D20 for ; Tue, 8 Aug 2023 10:01:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42AC23858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de Received: from excmbx-27.um.gwdg.de ([134.76.9.230] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qTJWs-00008X-Qv; Tue, 08 Aug 2023 12:01:31 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by EXCMBX-27.um.gwdg.de (134.76.9.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.27; Tue, 8 Aug 2023 12:01:31 +0200 Received: from fbmtpc21.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.27; Tue, 8 Aug 2023 12:01:31 +0200 Message-ID: Subject: Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h) From: Martin Uecker To: Alejandro Colomar , Xi Ruoyao , "Andrew Pinski" , GNU libc development CC: Adhemerval Zanella , Carlos O'Donell , Andreas Schwab , Siddhesh Poyarekar , Zack Weinberg , "gcc@gcc.gnu.org" Date: Tue, 8 Aug 2023 12:01:30 +0200 In-Reply-To: <08d7552c-d90a-ae84-4b7e-2f6f2136dd66@kernel.org> References: <20230710161300.1678172-1-xry111@xry111.site> <1efbe0b2dd8fefffc945c6734222c7d6e04cf465.camel@xry111.site> <10994861-c244-ba4f-70ad-86d66acf7277@kernel.org> <08d7552c-d90a-ae84-4b7e-2f6f2136dd66@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: excmbx-24.um.gwdg.de (134.76.9.234) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Montag, dem 10.07.2023 um 22:16 +0200 schrieb Alejandro Colomar via Gcc: > On 7/10/23 22:14, Alejandro Colomar wrote: > > [CC += Andrew] > > > > Hi Xi, Andrew, > > > > On 7/10/23 20:41, Xi Ruoyao wrote: > > > Maybe we should have a weaker version of nonnull which only performs the > > > diagnostic, not the optimization.  But it looks like they hate the idea: > > > https://gcc.gnu.org/PR110617. > > > > > This is the one thing that makes me use both Clang and GCC to compile, > > because while any of them would be enough to build, I want as much > > static analysis as I can get, and so I want -fanalyzer (so I need GCC), > > but I also use _Nullable (so I need Clang). > > > > If GCC had support for _Nullable, I would have in GCC the superset of > > features that I need from both in a single vendor.  Moreover, Clang's > > static analyzer is brain-damaged (sorry, but it doesn't have a simple > > command line to run it, contrary to GCC's easy -fanalyzer), so having > > GCC's analyzer get over those _Nullable qualifiers would be great. > > > > Clang's _Nullable (and _Nonnull) are not very useful outside of analyzer > > mode, as there are many cases where the compiler doesn't have enough > > information, and the analyzer can get rid of false negatives and > > positives.  See: > > > > I'll back the ask for the qualifiers in GCC, for compatibility with > > Clang. > > BTW, Bionic libc is adding those qualifiers: > > > > > I am sceptical about these qualifiers because they do not fit well with this language mechanism. Qualifiers take effect at accesses to objects and are discarded at lvalue conversion. So a qualifier should ideally describe a property that is relevant for accessing objects but is not relevant for values. Also there are built-in conversion rules a qualifier should conform to. A pointer pointing to a type without qualifier  can implicitely convert to a pointer to a type with qualifier, e.g. int* can be converted to const int*. Together, this implies that a qualifier should add constraints to a type that are relevant to how an object is accessed. "const" and "volatile" or "_Atomic" are good examples. ("restricted" does not quite follow these rules and is  considered weird and difficult to understand.) In contrast, "nonnull" and "nullable" are properties that affect the set of values of the pointer, but not how the pointer itself is accessed. Martin