From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by sourceware.org (Postfix) with ESMTPS id C4B883858D33 for ; Wed, 9 Aug 2023 10:42:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4B883858D33 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 (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3A3FF624F8; Wed, 9 Aug 2023 10:42:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D6CEC433C7; Wed, 9 Aug 2023 10:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691577746; bh=+TfB0XJyMMXSdXICRG0FoihvYtbmg+y73Q6vp7UjVUE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LBfoiW96I2ZHdNmzQeiKd2L3LpkS3ewk4lWEfzpsNHIEYAtEpqqH39Qh3Z5anag9F lMimoemR0vAsWNdYhB1Y0QcWeKoiHBMmEFgHhkvRXYOYvvoxy1ub6y5sgCB4uAzwfU rDE+1AdzrJJfpgf7yfTB6YPTkM91/IhaNOezB1Y6oYlojYXJTiOr01X39VoosJnIwz uLRDTo7hJPKafCLoJstCwBr/K3z6qEgYaGKRFHJWppHtoy6aUFzFy9CiyZWOMkRUwe rlBQ7I6xOOcD6XdPz6dM5bQCLVd6gEe912lsna5LKzWVaohFD7+KJtZqpqWupUD4ks 37m+Px/gWBeWw== Message-ID: Date: Wed, 9 Aug 2023 12:42:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.1 Subject: ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer) Content-Language: en-US To: Martin Uecker Cc: Xi Ruoyao , Andrew Pinski , GNU libc development , Adhemerval Zanella , Carlos O'Donell , Andreas Schwab , Siddhesh Poyarekar , Zack Weinberg , "gcc@gcc.gnu.org" , enh 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: Alejandro Colomar Organization: Linux In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------C7Xnq0bCmaO2MOCI2ZCu8R0B" X-Spam-Status: No, score=-4.3 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: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------C7Xnq0bCmaO2MOCI2ZCu8R0B Content-Type: multipart/mixed; boundary="------------KiygEzkdkBbAWjNCimKZXykK"; protected-headers="v1" From: Alejandro Colomar To: Martin Uecker Cc: Xi Ruoyao , Andrew Pinski , GNU libc development , Adhemerval Zanella , Carlos O'Donell , Andreas Schwab , Siddhesh Poyarekar , Zack Weinberg , "gcc@gcc.gnu.org" , enh Message-ID: Subject: ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer) 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> In-Reply-To: --------------KiygEzkdkBbAWjNCimKZXykK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Martin, On 2023-08-09 09:26, Martin Uecker wrote: > it is a bit cumbersome to use, but one can use [static] > instead, which gives you the same static warnings. >=20 > [static] does not work with __builtin_dynamic_object_size, > but maybe this could be changed (there is a bug filed.) >=20 > I am not sure whether [static] should imply [[gnu::nonnull]] I have a gripe with ISO C's [static]. As you mention, ISO conflated two functionalities in [static]: - The size of the array passed as argument must not be less than the size specified in the parameter's []. - The pointer must not be NULL. And there are valid cases where you may want the first but not the second. Or the second but not the first (that's the case for _Nonnull, of course). In fact, it's so badly damaged, that it prompted a proposal to ISO C of using [static 1] as an equivalent of _Nonnull in the prototypes that accepted a pointer that should not be NULL. However, that proposal didn't include the functions that actually take arrays as input (because they are taken in the opposite order, so array syntax is not legal). Don't you find it ironic that ISO C could have used array syntax for pointers and pointer syntax for arrays? I do. As for when one would want to mean the first (size of array) but not _Nonnull: for a function where you may pass either an array (which should not be smaller than the size), or a sentinel NULL value. Nevertheless, I floated the idea that [static] is completely unnecessary, and nobody has yet been against it. GCC could perfectly add a warning for the following case: void foo(size_t n, int a[n]); int main(void) { int a[7]; foo(42, a); } Nobody in their right mind would specify a size of an array in a parameter and expect that passing a smaller array than that can produce a valid program. So, why not make that a Wall warning? And so [static] would be irrelevant in GNU C, because well, what does it add? In fact, I like that [static] is so badly designed, because then we can repurpose plain [size] to mean the right thing, which would produce cleaner programs ([static] just adds noise to the source). What do you think of giving [42] a meaning, instead of just ignoring it? Cheers, Alex > which would then also trigger the optimization. I think > clang uses it for optimization. >=20 > Martin --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------KiygEzkdkBbAWjNCimKZXykK-- --------------C7Xnq0bCmaO2MOCI2ZCu8R0B Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmTTbYgACgkQnowa+77/ 2zJzAQ//ZqJN9p5Yba7UPpBF+ORf0oz24E+v5YhpspYjadN6duK1KIpZwaucDrID MyE1HUwXob8ysKVjU0HwazPviq9GXzRmUL1LUsnlRqm9wHMvOTUdIBUnc0SBxb5i HBT1siKFXnSLV07dMpy35ODtDCtLEk2ImQfpY5RcR8DizVI9Vk7twJqLvpIrKWuy C8R3UF0z/QK4MMrfkEUgl4nijmW0NPoyEW/lNepgfMZqD7XIG+/VlgnZvJZ0TzX7 h8o9t0wNddjElN6q+3Nlstys9WdTK6BQyNuEtRFa0LJG7lG253waAP0fPsZELQsY MGT5A4U5nSZL+CoXP3qtT6ybPfjjPJ+irZpXSfoLmVPL4pcPtIiFpmWWw1ynFwSI ioIbrS4bMYiTvQzYvgyAmh1I7hyOH7HDAgrDReaZZ3z4cGUEcIxWA8ktSwcGG733 CIF4nfCyZr+4yZ+TmqStZjAu2wG3PUxSfEToOBR41HYENMz7x4vYkVSIjl7yy/Yw aoYzfJ3B986/CH7TRluR3PFAF5NiBx+7eIfRXW36KQ3RXq+WwMpJerEh42s6Qd6W gEplci4pLlDv6X8HUt0ZQSMUJqKc4710QriErAdKi8iBfwwv5mm+ZCuFzNIPmqmh bYtowvXJgD/bbVlI5ZJ5qpVCrUbfd6JYVMJjxCGtyZqaWhRtmMw= =NY7f -----END PGP SIGNATURE----- --------------C7Xnq0bCmaO2MOCI2ZCu8R0B--