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 636C63858410 for ; Sun, 3 Dec 2023 11:35:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 636C63858410 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 636C63858410 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=1701603354; cv=none; b=kyVbGqJXqg/5MsD7IPjbrQ1N18Lv15EVSrwbo6FzMDr+kK1/IFcDe6sqY3s6OjR0MbFWJnarJLmD/ZpgOYMwUbnZvqkgLI3iJobuYUIgsx9WKZNpJaJabWGxtphtqBXUOV2fATdRoh4i+RQjb5TwSLbMzIjWX3vKqeqQx2iptjQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701603354; c=relaxed/simple; bh=X+MsF6H0QYJXhaF9XktDCAmSsaFWfyDkHEKONln6REQ=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=DU/7YffRnqVPFG3oVcceDt/mnabqMFYPXlssoYYXJq3xgSSjTg5d6NfmN0EmjYlzAGwBpb4pK9dFTkpbntBeKo45zdvpnPfeq2kCJl7EiFHCDZX3r457zBsBA1yzm6YBaim3X2YxvvQghueZDQEM5sSXXK3tU11wEUbigzgsk90= 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 E2ACB60BCA; Sun, 3 Dec 2023 11:35:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EEE6C433C9; Sun, 3 Dec 2023 11:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701603352; bh=X+MsF6H0QYJXhaF9XktDCAmSsaFWfyDkHEKONln6REQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tjcEEd93/s2nliRBFHBTXuuSLjvYtiSuVdzYVFhD4K+MWrPXJ/aNfG95zQwuy0UFz D2FUAMMM9xN3rC2DAYRnbo+j9OEcMyMTK0tqI2Sf8PfBEk+0AKH6BBVQ8t3R7ZKPLC NOPskqp6+3gYIdkQgFVmYr/XW8IT67ytFXHpWQKwI14+DAP3oiZKmh5kRXUsj7lrbC rjJh2dspNUhJcWUyPZSkScYI5ftl9UzkHuSga42dBN3DLWVgasw5Rwnem94Ih3tpWa EYBySWn3JNZ5LHTks1cNE/Vuxj4eq7P1B5LL24GwZiyV7IKOYxRHjWU8o5gxvRwKWI c133F0Rz1qQYQ== Date: Sun, 3 Dec 2023 12:35:42 +0100 From: Alejandro Colomar To: Amol Surati Cc: libc-help@sourceware.org, gcc-help@gcc.gnu.org, Guillem Jover , libbsd@lists.freedesktop.org Subject: Re: restrictness of strtoi(3bsd) and strtol(3) Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zG/S+oYAhyKe/Dw/" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.6 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: --zG/S+oYAhyKe/Dw/ Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Dec 2023 12:35:42 +0100 From: Alejandro Colomar To: Amol Surati Cc: libc-help@sourceware.org, gcc-help@gcc.gnu.org, Guillem Jover , libbsd@lists.freedesktop.org Subject: Re: restrictness of strtoi(3bsd) and strtol(3) Hello Amol, On Sun, Dec 03, 2023 at 04:29:07PM +0530, Amol Surati wrote: > The section "7. Library" at [1] has some information about the 'restrict' > keyword. >=20 > I think the restrict keywords compel the programmer to keep the string > (or that portion of the string that strtol actually accesses) and the > pointer to a string in non-overlapping memory regions. Calling > strtol(p, &p, 0) should be well-defined in such cases. That would justify the restrict on char **restrict, but it doesn't justify the const char *restrict. I think a more appropriate prototype would be long strtol(const char *nptr, char **restrict endptr, int base); The above means that endptr points to memory that is not pointed to by anything else in this call. But any of the following is somewhere between confusing and a lie: long strtol(const char *nptr, char *restrict *restrict endptr, int base); long strtol(const char *restrict nptr, char **restrict endptr, int base); long strtol(const char *restrict nptr, char *restrict *restrict endptr, int base); These 3 from above all mean the same thing: nptr, endptr, and *endptr each point to a different memory region. That's of course a lie, because nptr and *endptr may alias. The formal definition by ISO C, which is in terms of accesses, seems to be compatible with these uses of restrict, because as long as the function doesn't access the memory, it doesn't matter if they overlap. However, that definition of restrict is useless IMO, and still doesn't justify why the compiler isn't complaining at call site, where it can't know that strtol(3) won't use **endptr. Cheers, Alex --=20 --zG/S+oYAhyKe/Dw/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmVsaA4ACgkQnowa+77/ 2zIUnA//U87JjGFlBBbmKNbAydwkJ2bB8ovrzd83UdclDtCW91UBG1WBzlU1ur95 gtb9FCenZRilWAp6KAhywWiJeVsmGJJnavR2aJyHI4ug3UzujDVB/qJcU9cyOdt+ cD0n/qo5yAwjL8YzNnacW9mOdv7Ybqw4+uOExdCn2idLlERWg7jA+uhPq9f/+qm0 XwNbyGPUG2yK6oWZyxQIe8BGis9jCoNScIRpFkMpY5ScsY/lWHPq9i0TMJBqqW1g hxFUhVm2esrs49A8sYCUo0653NGXO3Ot/JuU1W7xn2vAJp6bOPW8JFi/oqba9HjU TW7jW95EjK3pjBUK+0au70so6jDJR4sWDhFXr8S9ODu9tzyoPKKmYpnQida8X3Kf KQkonY93o1J8ckuMXHsepMGr/GIjfi4eh6zr4FLtKOLxvTeG22Enr+YEdnYNBtn/ tw5GvwVv5skcB4OEyroTteN68RmY+MrxeWJ1V/oiW6Ub521ta7GghR0wIqF1sXdq 6euZth/YsZv6E9NKoyQ5ZzH1MtLy8b3wLIvZtVWkrEOur059YHR6/PepFXgu/8qB sci07+61/8YnnaTYysDGLEVE8yTHA+SPJSTFivqHPQleqm+udbVUNRPDoXZ0CUMa Ckl/kS7CmvMC+vb0nn9h9L2lnB35yVDxbjE4eKb8O6jcpgXd0eM= =/7OX -----END PGP SIGNATURE----- --zG/S+oYAhyKe/Dw/--