From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by sourceware.org (Postfix) with ESMTPS id 6DF48385E00E for ; Tue, 26 Sep 2023 12:05:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6DF48385E00E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 77097B80FEC; Tue, 26 Sep 2023 12:05:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 079C6C433C7; Tue, 26 Sep 2023 12:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695729935; bh=5M+zvRGPwy/ltqz8948eaWZCZn0beUsEP11X4+RMyS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Sw5iYamXpLDMu7tobIm77nQfEkrTLuXYtK3Z2hcECau5BiBdy0toBwxyXOtSXqbG2 WnTMVEF/20Yg8Zo/hxm5Gs5Sep7zQxqbkTHZLNVU9bKIAjxzyrauQ3YPwCN9UxCAKc bnzZUg4Kl9GlM6lIdy1f5aS/EtH9F2HEoAmj66TP134WWda+lfgK+YSRB1/IPUjeaC 8E6MSXNDkev5BVloMgME93at3cm7Z3htuOJEqz8uqrEJtC0mi0rnnfvjJCwZ0rV7tX JVZm3ak9eFK6x1RLT2QAEC2BCkZxO0gWwZ6V3C20QpC8u7H5mVKzsXcz7EGPZ6wX4W eEMmpjLAy0aKw== Date: Tue, 26 Sep 2023 14:05:31 +0200 From: Alejandro Colomar To: Siddhesh Poyarekar Cc: Zack Weinberg , Xi Ruoyao , GNU libc development , Adhemerval Zanella , Carlos O'Donell , "'Alejandro Colomar (man-pages)'" , Andreas Schwab , Jeff Law Subject: Re: [PATCH v7] libio: Add nonnull attribute for most FILE * arguments in stdio.h Message-ID: References: <20230925115325.176968-2-xry111@xry111.site> <56b5212c-f280-4313-894c-fd66123b1d64@app.fastmail.com> <6c908185-9559-d99f-5410-780dca8806d1@gotplt.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="peqox7juchuvrx2r" Content-Disposition: inline In-Reply-To: <6c908185-9559-d99f-5410-780dca8806d1@gotplt.org> X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: --peqox7juchuvrx2r Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v7] libio: Add nonnull attribute for most FILE * arguments in stdio.h MIME-Version: 1.0 On Tue, Sep 26, 2023 at 07:24:37AM -0400, Siddhesh Poyarekar wrote: > On 2023-09-25 15:10, Zack Weinberg wrote: > > I still think this is a dangerous idea and, if we do it at all, we > > should do it *only* for compilers that have a *documented guarantee* > > that control flow paths that provably pass a NULL pointer to a __nonnull > > argument will *not* be treated as unreachable. If I understood the >=20 > You're essentially asking the compiler to *define* a behaviour when faced > with undefined behaviour, which doesn't seem like a reasonable request to > me. Likewise for glibc; we don't often go out of our way to specify an > implementation defined behaviour when the standard specifies that behavio= ur > as undefined. >=20 > > previous discussion correctly, GCC currently does not do that, but there > > is no documented guarantee that it will *never* do that, and nobody > > chimed in from LLVM's side. > >=20 > > (It's probably fine if compilers treat calls that pass a NULL pointer to > > a __nonnull argument as noreturn, or if they replace them with a trap > > instruction or a call to abort(). The danger I foresee is from any > > circumstance where NULL checks and side effects that happen *before* the > > bad call can get deleted.) >=20 > This (traps on undefined behaviour) was in fact discussed at the GNU Tools > Cauldron last week as one of the things that the compiler could do for > undefined behaviour in general, essentially subsuming sanitizers into the > compiler proper. One must realize though that (1) this would be 'best > effort' on behalf of the compiler and (2) it's going to have overheads, > albeit modern, speculating processors may subsume that overhead, which > however is precisely where Spectre-like flaws operate... >=20 > Trying to make undefined behaviour safe in the compiler is not a bad idea= at > all, but guaranteeing fixes to application bugs in the compiler is a > terrible idea IMO. >=20 > > (I think this policy should be applied to *all* instances of __nonnull > > in glibc's headers, not just new ones.) >=20 > You're asking for a change in position in glibc, which shouldn't block th= is > current patch IMO, which aligns with the current position in glibc. I tend to agree with the GCC side of things. UB is UB. Making it safe at all costs is not necessarily a good thing. What I think could be done is using a qualifier, similar to const / restrict, to be able to=20 statically analize the code for UB. Still, I don't think this patch should be blocked by such a discussion, which would probably take a long time. Cheers, Alex >=20 > Thanks, > Sid --peqox7juchuvrx2r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmUSyQsACgkQnowa+77/ 2zK6IBAAmPMg2rasdcCc/xDxaSbSDj5B35lkIUXhGapM39l9UtApRRnfMF+Ynhol Y+nrf3suRqP7QcqEYXgfjiQEbgKqudrqpQMeCTd3JXnQ/GPe2hj2tfcaxsSPh4UW tr69kaUpTRJR8IeMDnLt3L8pknJkhGyeTuEZkKPDQLfYfLLrneDBo7/O75jBjY+r +E0AMqR7BO5VkLtB/jaxVNmHzRRx1e369RWNtLeXtn71EGwIiX9iGmTAC9DO9PIg 93DBnYLf6skkvJqvwadD1bnPxqMrIi7HfRgo203KWfg3/a18zbwlKTbZJtGkwFJp rkqSIjL5uzSHw5DFxxnA64wP2P6vKx1XAqD/Fjeoamjr8dt4B3iFFVKPCC02rXe8 A/AqNz3u3WU0uvBnkZCvOddWAbDlJJzYfu3V8PQiLIHds8MJc/eFOC9RT/pDpYn+ 9UjUBFVUPz4H4tXGdVp+N11IHhUiMGZirrKY9X2PbSbuAA9D3W5r5sdei8mia1nG xUIU1x7QOxBNDTmqfGNSKQ6YKBFkMdoVMOocLLw+RIGpKr+bEE30DhEGAcCSKphl r3uB7JiUD8uoLvnKZ5CDqkfjMnG2oppIokhLvcrs7nsgxdm5vj83bDaEGqLTylYA 5FbvRpJsyuRlOGE/mjqL+42NMwscL451rJXDnItOVkQYK2KXAOg= =EAE+ -----END PGP SIGNATURE----- --peqox7juchuvrx2r--