From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 0E6623858CDA for ; Tue, 11 Jul 2023 00:52:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E6623858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <20230710161300.1678172-1-xry111@xry111.site> <60947356-1710-4658-9169-9535505befd4@app.fastmail.com> <5d050e86-4c98-de22-5ef0-4cc9ead273d7@gotplt.org> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: Siddhesh Poyarekar Cc: Zack Weinberg , Xi Ruoyao , Adhemerval Zanella , Carlos O'Donell , "'Alejandro Colomar (man-pages)'" , Andreas Schwab , David Malcolm , libc-alpha@sourceware.org Subject: Re: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h Date: Tue, 11 Jul 2023 01:51:41 +0100 In-reply-to: <5d050e86-4c98-de22-5ef0-4cc9ead273d7@gotplt.org> Message-ID: <87bkgjxoah.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: --=-=-= Content-Type: text/plain Siddhesh Poyarekar writes: > On 2023-07-10 14:56, Zack Weinberg wrote: >>> Would it be more acceptable to you if this gets wrapped into fortify, >>> i.e. it gets enabled if _FORTIFY_SOURCE is defined? >> I tend to agree with Xi that having the presence of __nonnull depend >> on >> _FORTIFY_SOURCE would cause more problems than it solves. Also, since >> several Linux distributions enable _FORTIFY_SOURCE by default, we'd >> still be risking significant breakage if we shipped that in 2.38. > > I'm less concerned about the distribution breakage because they'll > more likely than not get fixed; in fact my suggestion to put it behind > the _FORTIFY_SOURCE wall was precisely for that reason. I'd like us > to weed out such cases in the distribution and get them fixed rather > than maintaining status quo. I'm relatively more concerned about > non-distribution applications that tend to, e.g. disable security > features because they see them as either performance hindrances or > want some legacy broken code to just work. > > Of course, I'm not concerned enough about these applications (sorry) > to insist that it be put behind _FORTIFY_SOURCE, but I think it's a > reasonable compromise. That doesn't directly solve the analyzer > problem though. Maybe if it's OK to have the analyzer affect codegen, > we could have the analyzer define _FORTIFY_SOURCE=3 and thus enable > additional diagnostics too, like the __wur that also gets enabled only > on fortification. Is that something worth considering? I like this as a compromise, at least for a temporary gate for us to feel more confident about a big-bang switch to the remaining missing annotations in headers, but - like you - I'm not convinced it's necessary. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZKynx18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCU2gEA8XvchSUUU45XQtwRNkwERwCewXOOk99V8d6F m2PSj4IA/0gEW+n/KyoNUqolmzvbBjxwXh0/jnWP+3S+varjC1UD =hQYR -----END PGP SIGNATURE----- --=-=-=--