From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from caracal.birch.relay.mailchannels.net (caracal.birch.relay.mailchannels.net [23.83.209.30]) by sourceware.org (Postfix) with ESMTPS id 245233858D20 for ; Wed, 9 Aug 2023 01:11:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 245233858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 13954C0644; Wed, 9 Aug 2023 01:11:51 +0000 (UTC) Received: from pdx1-sub0-mail-a312.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 8A8DFC08B1; Wed, 9 Aug 2023 01:11:50 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1691543510; a=rsa-sha256; cv=none; b=0y+Iu+HFgd1O9Tlz76A3WoOFxILpHm0+M0nYQG9FepLlyED7pewBr2xUSSjBYHmTY53BE7 iFcupChXoGJggGfO/SJdV2b1SMIgwwi+mIiq4RFTU8MuALSAMgpsmkht7GIc823slK49ws 0mAtJf1iNZP44714oatOyhbuldsH2wfH2P5kR1EVxcMZxD+l07i7of+jOUH7bjhD3L0ywf UbofXVffSmXUweBvq9R5s1qO8tkFLcifBGaGINO8x/A0fwKjfOJ9x/zxEIwDsh850+ejlG S7sGLgf1yeeyBDlkRARH36kbT8eqrY11mT2kmgfT8xoCwstyFN57hUGSthT1tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1691543510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IrDoz0LhnGOMgIlSiEQPUdTM++XoyJKNrNstShxh7+s=; b=lr3BNTUnFKqQGtvBiN57FJ6I5x678s6qJ93XsKYyGAZ3kOE/nKMH736O/Ti+SPhKECZ7e9 LPylrvMREG/rHKgyq74i7SkRMbCq3AynTYHilDgal9+GQbJytgoLdvK3nJUQ/WVRwJUVvO o8MXmDu4wYJD7Ah2jAjROoY4/mJgPuujQevYFR9QB4WpB3SeACw5kOWepqtySf+8bMg720 c5EX+3CT3ymOXFuuC+lHfLsvA9Qqbin27TEF4USH1IsQBIVZYU+lNs6t+Fuhjp3bVxt4ei srpvq79FnkgiKl7pn/rd0c4mElKLtZtx7KViESTt7HZkZcAZpVNlo2x4jCDtZA== ARC-Authentication-Results: i=1; rspamd-849d547c58-d7bzp; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Chemical-Cooperative: 2e60e9c32c2885b1_1691543510891_3690439453 X-MC-Loop-Signature: 1691543510891:706271606 X-MC-Ingress-Time: 1691543510891 Received: from pdx1-sub0-mail-a312.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.110.206.19 (trex/6.9.1); Wed, 09 Aug 2023 01:11:50 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-184.dsl.bell.ca [142.113.138.184]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a312.dreamhost.com (Postfix) with ESMTPSA id 4RLBps3Rg7z76; Tue, 8 Aug 2023 18:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1691543510; bh=IrDoz0LhnGOMgIlSiEQPUdTM++XoyJKNrNstShxh7+s=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=TY0xKyQ6vU5r9Ryj1T4WXFjNU6NW7ZJ5HqOYUyANtK9RY4O5AxB0JmaytNXgRhvpL qZlbjOfSpjYvoZOJEVt8XUOHy+y3BkiLoHt8sRYWOrXoKYzmB4qs1P/GchOcJToI8E coWzlP80UkyTVQ+6fEOHyBZmUayyzEonFXK+665XGx6gbqNiOkkzYp1juuvVouga3p Skl3/eUEd7eFRtRensP0ZZsI8NN3ZJ3lT3wtdW6q+ib+xsBIQxZllR8o95hMyjaEy1 2EipX+UJcqVNm5VvUwkLVNoeWThBkIbx9dTGUw7CpxXZ1/wbj20CqnDZqQntce461M NRNimItePPs8A== Message-ID: <454482b7-6a19-680a-a6e4-5151917046f1@gotplt.org> Date: Tue, 8 Aug 2023 21:11:47 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h) Content-Language: en-US To: enh , Martin Uecker Cc: Alejandro Colomar , Xi Ruoyao , Andrew Pinski , GNU libc development , Adhemerval Zanella , Carlos O'Donell , Andreas Schwab , Zack Weinberg , "gcc@gcc.gnu.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> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3032.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,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: On 2023-08-08 20:14, enh wrote: > (bionic maintainer here, mostly by accident...) > > yeah, we tried the GCC attributes once before with _disastrous_ > results (because GCC saw it as an excuse to delete explicit null > checks, it broke all kinds of things). the clang attributes are AFAICT based on earlier discussions around this patch, the NULL check deletion anomalies in gcc seem to have been fixed recently. > "better" in that they don't confuse two entirely separate notions ... > but they're not "good" because the analysis is so limited. i think we > were hoping for something more like the "used but not set" kind of > diagnostic, but afaict it really only catches _direct_ use of a > literal nullptr. so: > > foo(nullptr); // caught > > void* p = nullptr; > foo(p); // not caught > > without getting on to anything fancy like: > > void* p; > if (a) p = bar(); > foo(p); > > we've done all the annotations anyway, but we're not expecting to > actually catch many bugs with them, and in fact did not catch any real > bugs in AOSP while adding the annotations. (though we did find several > "you're not _wrong_, but ..." bits of code :-) ) I believe it did catch a few issues in the glibc test cases when we enabled fortification internally in addition to flagging several "you're not _wrong_, but..." bits. In any case, it's only enabled with fortification since we use that as a hint for wanting safer code. > what i really want for christmas is the annotation that lets me say > "this size_t argument tells you the size of this array argument" and > actually does something usefully fortify-like with that. i've seen > proposals like https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/ > but i haven't seen anything i can use yet, so you -- who do use GCC > which aiui has something along these lines already -- will find out > what's good/bad about it before i do... I think a lot of this is covered by __access__, __alloc_size__ and the upcoming __counted_by__ attributes. There are still gaps that something like -fbounds-safety would cover (I think -fsanitize=bounds and -fsanitize=object-size further cover some of those gaps but there's a general lack of confidence in using them in production due to performance concerns; fbounds-safety has those concerns too AFAICT) but that gap is getting narrower. Thanks, Sid