From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 46AD93858CDA for ; Mon, 10 Jul 2023 20:44:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 46AD93858CDA Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1689021886; bh=9VKqX6IzDixyCwWhtfe8n4bJYXe8MJA/9WuYHc6zofc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=RGEkdkx0OVf72nh+B1U7sjYASjlRfzUyeitwcEjrhrMGjejgP2ZcoydIzRqDKU2fU OjWvnAJ+4OfcKDraiU5egojmqQOhaRWSMS14s4v2aeU316yUf9z0aMqSMFxarb/Cmo AFeu7K9k8GVPRt6oQ3XuAKtOzGm2zUXz8e/a86OI= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id D6BF165BED; Mon, 10 Jul 2023 16:44:44 -0400 (EDT) Message-ID: Subject: Re: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h From: Xi Ruoyao To: Jeff Law , Siddhesh Poyarekar , Zack Weinberg , GNU libc development Cc: Adhemerval Zanella , Carlos O'Donell , "'Alejandro Colomar (man-pages)'" , Andreas Schwab , David Malcolm Date: Tue, 11 Jul 2023 04:44:43 +0800 In-Reply-To: <25b31a74-5f06-1cce-dca5-ae84666c92b7@gmail.com> References: <20230710161300.1678172-1-xry111@xry111.site> <60947356-1710-4658-9169-9535505befd4@app.fastmail.com> <5d050e86-4c98-de22-5ef0-4cc9ead273d7@gotplt.org> <18affbe3-00c1-1cb1-6860-f7c78585f52b@gotplt.org> <25b31a74-5f06-1cce-dca5-ae84666c92b7@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Mon, 2023-07-10 at 14:33 -0600, Jeff Law wrote: >=20 >=20 > On 7/10/23 14:23, Xi Ruoyao wrote: > > On Mon, 2023-07-10 at 15:46 -0400, Siddhesh Poyarekar wrote: > > > On 2023-07-10 15:35, Xi Ruoyao wrote: > > > > > Of course, I'm not concerned enough about these applications (sor= ry) to > > > > > insist that it be put behind _FORTIFY_SOURCE, but I think it's a > > > > > reasonable compromise.=C2=A0 That doesn't directly solve the anal= yzer problem > > > > > though.=C2=A0 Maybe if it's OK to have the analyzer affect codege= n, we could > > > > > have the analyzer define _FORTIFY_SOURCE=3D3 and thus enable addi= tional > > > > > diagnostics too, like the __wur that also gets enabled only on > > > > > fortification.=C2=A0 Is that something worth considering? > > > >=20 > > > > Or can we just guard the __nonnull usage against __GNUC_PREREQ (x, = 0) > > > > where x is 12 or 13?=C2=A0 In the recent GCC releases the optimizer= won't > > > > kill a side effect before an UB so it should be much safer (see my = reply > > > > to Zack), and it's unlikely they'll use the latest GCC for some leg= acy > > > > broken code. > > >=20 > > > It depends on whether that's a deliberate design decision in gcc (and= we > > > should probably look at what clang does too) or if it just happens to= be > > > so today because of some IR layout coincidence. > >=20 > > Allow me trying to get some clarification...=C2=A0 Jeff has said > >=20 > > "I thought during the introduction of erroneous path isolation that we > > concluded stores, calls and such had observable side effects that must > > be preserved, even when we hit a block that leads to > > __builtin_unreachable." > >=20 > > during the reviewing of some GCC patch.=C2=A0 So is the "must be preser= ved" > > statement applies generally, or only for -fisolate-erroneous-paths-*? > It applies in general. >=20 > Essentially up to the point where the UB happens we have to preserve=20 > visible side effects.=C2=A0 After the point where UB happens anything goe= s=20 > and our goal has been mark the paths through the CFG as dying at that=20 > point and forcing an immediate halt of the program (via __buitin_trap()). >=20 > There this all gets fuzzy is something like the NULL pointer property=20 > where the fact that a pointer must be non-null can backward propagate. > ie, if a parameter is marked as non-null, then we will mark the=20 > corresponding SSA_NAME in the compiler as non-null.=C2=A0 Thus if there w= as > some comparison of the SSA_NAME against NULL (perhaps well before the=20 > call), we'll optimize away that comparison. So, for the SSA: int g () { int x; int * local_p; int _6;=20 : local_p_3 =3D p; if (local_p_3 =3D=3D 0B)=20 goto ; [INV] else goto ; [INV] : puts ("oops"); : x_5 =3D f (local_p_3); _6 =3D x_5; return _6;=20 } the bb 2 and 3 still may be optimized away (though it currently does not happen)? --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University