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 554183858D33 for ; Fri, 26 Jan 2024 23:25:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 554183858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 554183858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=139.178.84.217 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706311511; cv=none; b=kIZvcY39mAYcHOfPvkO8D9R44HaWyKtd1U8/S77wu/YivZ54kT3zqzXnIvwljL3cTFOXFprDy8jmWDUliwPtdxswRdEB+NDvlBExw2cuIs2acLbMZz9lNzeOyoVzhjCXgDeydFNrLuzXt4KM911yQx7isafum6ynvTckH2f/XfA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706311511; c=relaxed/simple; bh=MccDbN3nhHstjGY+KGXwT6Vh//Bvlc5uhMSyvYDIn0k=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ikufKtyT27FdCmXuPY2KPbdClXX906Bja74NzbBQQ15tfXf8wFApoETAJjMWSqST6cZ8CwFGybFaumNbNrkaCWR7SdtXDW2OhQNnyD96jb4kJ/7iDgKLV2dcs1Tmc5Awb6isA5smnO8bX5u4LY+3M95TUv3RZp59Tjkemz+E7lM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B366F62337; Fri, 26 Jan 2024 23:25:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D082C433F1; Fri, 26 Jan 2024 23:25:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706311509; bh=MccDbN3nhHstjGY+KGXwT6Vh//Bvlc5uhMSyvYDIn0k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y5RCHWLh1wLOzQFpmyvUU7BuhrmYmfOZNb2QphzdhtrTln4TPPgKG/ngXCVAAYuhI K4IgsnGM056Pevbcj8tbCKq9YQ0WbG2aHvF9A2JSXsLeFNDeJVG13ObHf+Jb4BsIV7 k2AW0pwjBbXluzD5W7UYCAlNRZpVSJGWeVnaqjq96pRoc+yID8t/ccwwF9/5SLwcl3 Ta9kCcOPHCUi4vBdwQTZ1D+Yj8H86GORhNMETBXq9hOebdUvbN7/1ZGloeUBSU71c3 eMhZPHF0EDuPdeuZ8U+nCMPfck9JRRuDn05i66syJDocvPGlL9FtNHT5MaQC6B8U5X XfZGF/N4XjfMw== Date: Sat, 27 Jan 2024 00:25:05 +0100 From: Alejandro Colomar To: DJ Delorie , Russ Allbery Cc: Andreas Schwab , libc-alpha@sourceware.org Subject: Re: free(3) const void * Message-ID: References: <877cjv4wav.fsf@igel.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j6bPqExmQVvWQiSX" Content-Disposition: inline In-Reply-To: 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,T_SCC_BODY_TEXT_LINE 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: --j6bPqExmQVvWQiSX Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Jan 2024 00:25:05 +0100 From: Alejandro Colomar To: DJ Delorie , Russ Allbery Cc: Andreas Schwab , libc-alpha@sourceware.org Subject: Re: free(3) const void * Hi DJ, Russ, On Fri, Jan 26, 2024 at 04:47:38PM -0500, DJ Delorie wrote: > Andreas Schwab writes: > > Also, objects in the heap are never read-only. >=20 > I thought of that, but using "const" in a program can mean something > other than "the object is read-only". It can also act as a promise to > the user and/or optimizer that an object is not written to, even if > doing such is possible. >=20 > So the original problem of "having to keep a non-const pointer around > just to free it" is valid. My post was just to put me in the "too bad, > deal with it" category ;-) After some fresh air, I've been thinking about what Russ said, and it makes a lot of sense. While the attribute [[gnu::malloc()]] can tell where some object is definitely terminated, there's no way to tell via attributes where an object is definitely not terminated; you can only guess that an object may or may not be terminated when a function doesn't use the attribute. So having `const` imply that an object is not terminated is a feature. If that means that we need to live with the fact that we need a writable pointer to be able to free(3) an object, I guess the answer is indeed "too bad, deal with it". :-) Maybe some day, attributes will give us full certainty about object lifetime, but that day is not today. Have a lovely night! Alex=20 --=20 Looking for a remote C programming job at the moment. --j6bPqExmQVvWQiSX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmW0P1EACgkQnowa+77/ 2zKG3BAAoRfkGrfu9HhuhJ2+MIYr2BhwUjXITc+FShILiLm4TVYu2bvD+9tb+vPX YhBHPeiUenkwvLWAR79sOs6SnsydTmcjF0enl3W4E3tFzrkwkxSK7AjVGwhAIbI5 3Gxcw2Vc4EeQg5eyztUlpmxMOMgQjqXSzrMFYoRto9Ll3XZoJrtSomBm2qU7tPMk jOG1wAQgzUzG8cjEOm+DaeJJQz2HTa+aW427RFiEvpK4aGXioUNAxDIEnKSd/JFl aBXMnUiec6NtN2jtv8ekBXP0lMe04oZAk2NA5Ag+hjz+cHp8mNyWOBCc/V/sIav8 jYf09hhWAa70/MbD6Hwa3RU53M7nU3KouENyMHLqjGEN5yTdLcz6oBF6mG5OrJ95 5CU4w488AnfwubxlYJdcqEcqFn09XtZ5YjxLJImtVZcMRKtUFyeBCwUY3kK/sDzg 9/5ygAZ9ImVX3h3VHoYI48+cEwl0hbnw9WELXQc1JUBHB7BzjKjuCimxygmTnBiO YKa3oQEDLpokXc7OE+xwvM2sHQCaWFVr8yyCtf1M+9bwicGnaH7PMUI90WiKKF/v 41Zysg7Os5Uo8aZAXBITtgikXPmop1OkcI7HvgY8A7u92tvy1DRfjf042rjQr1fx F7wFhVMmcqtzdfmlKfePDsxD56BU3fJPwBw7QeWdmBrG1V5Gzww= =YYGp -----END PGP SIGNATURE----- --j6bPqExmQVvWQiSX--