From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by sourceware.org (Postfix) with ESMTPS id 01358385E017 for ; Sun, 3 Dec 2023 16:34:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 01358385E017 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 01358385E017 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=145.40.73.55 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701621255; cv=none; b=FpQGhQO3BorFMQfmOTcxWUBzkRY9xBsEmQt0roIjHC9XPngSvG6sQld5+Ad9iG3FvLru7ls+1F78YwGy54LBs7SO5C4h1/mUod9pnFVNi7YCex5trbW9fHitur2KFXquD72cCQwQJnrR5ZkQJV8R8XIW+smJ4kQrVHlX1vGLrhw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701621255; c=relaxed/simple; bh=KBGsId0Erjbn4/oqoVTkwavcxRf9hAyP9NvZi2SBLzc=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=uLL4Nifp3PWEO2PpxdmuPPFQhcKaMaiGzfRQJStN4mK5dU5PZ/fH14EXjrm0MSsn+wNp0Em3+ktBI7sBR26GoCtrJeqpOneMCgF4gLzT3Mu4umJkJg4cQblCnjxI+s5+mOAkwDCNQ33lJH9jfDrsJVXUktjTCZ6N4WIBmXtVRrI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id EC0A5CE0C65; Sun, 3 Dec 2023 16:34:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0686CC433C7; Sun, 3 Dec 2023 16:34:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701621249; bh=KBGsId0Erjbn4/oqoVTkwavcxRf9hAyP9NvZi2SBLzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a0R6zuCYesnP6lFx8lsaNcvp8gZ1l79T0QhAZSWdhb5Afzklx2YBUh7BXMBo0B/ul 5WaQxsCLtBFp4u7lrfxDN+wGme52I/yChZF/u+WiEE0O1zxh1wVXOxpDIMANDZbdK+ do6dDms0e3eKIlC0+1ympw1iWsMajmdkRs0hv50O9SnbzR+2gLfc6dKpt5dQqxv0Wk xuFk+fV2MOo1zwTBiHKmhRzbg/C1HkBQJdrS94HUt+AYmXoInMZaie/z/I+sp4FZu2 Hk4nBkkPX5/GZxPN0mor6vMnqm+EoMKko5AM+2NyOToOqpuNhoAK4KswIe6cfji807 h5VWJNyXiRaHw== Date: Sun, 3 Dec 2023 17:33:59 +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="6mHsfCphvs371pEX" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.0 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: --6mHsfCphvs371pEX Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Dec 2023 17:33:59 +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 09:08:22PM +0530, Amol Surati wrote: [...] > Referring to the points you make later, removing the restrict-qualifier f= rom > nptr then explicitly permits *endptr and nptr to alias, as the types are = now > devoid of restrict-qualifiers. [...] > I think I understand. Since strtol is an external function, the compiler,= when > when compiling strtol(p, &p, 0), has enough information, in the form of t= he > strtol prototype and a call to it, to warn about the fact that nptr and *= endptr > may alias in a way that triggers an undefined behaviour. Exactly. >=20 > Based on how I understood the latest draft n3096.pdf, it is the write to a > char through *endptr (along with a read of that char through nptr) that > triggers the violation of the 'restrict' clause. The read and write need = not > be in a particular order. No major compiler warns, though, as evident by > an example at https://godbolt.org/z/a4xza5xna As you say, ISO C's formal definition of restrict permits pointers to overlapping memory, as long as only one of the pointers is dereferenced. > ------ > What sort of optimizations can a strtol implementation hope to achieve? > A couple of libcs discard the restrict qualifier when calling their handl= ers > for strtol. The situation with strtol doesn't seem to be similar to that = with > memcpy-memmove. >=20 > It seems that, as long as strtol does not assign a value to **endptr, it > continues to adhere to the std. To be pedantic, even reading a value from **endptr would cause UB. But yeah, the point is there: the standard's definition of restrict isn't very good. > The historical docs point towards a decision to stamp the prototype with > restrict under the assumption that (1) the string and the pointer to stri= ng > are in disjoint memory locations, This justifies the restrict on endptr. > and (2) the implementations would > use endptr for nothing else other than maintaining a position in the given > string. This is quite brittle. The restrict on ntpr should cause the compiler to scream. I'll report a missing warning on bugzilla. Cheers, Alex --=20 --6mHsfCphvs371pEX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmVsrfcACgkQnowa+77/ 2zKXABAAiE/gM9/rNVLqrc+SRlmNAtyKRe+vjM56rNINpFAnkMjUGvrfxEyD3yxd KyhkVWiX/kwCXmB3cx2hqlRYOqFJmx0WazNr/qsC3E2Gi4MMvT2BRT3K9oR8tSle d28Ti4t6fkBz1oj1CBvS+rU3d527D2yBwkhJGpcI2CG4NGsniT4Nqk0Qayr1n9tH yC9+sXagKhcwPSm4nrC4n/fmU8jGdKJKIgLbIcKR0wqAqruTQ00zitOBvNH5JQ+J 0KGtk3OgIZ1sBPRJ2O8VEbuPhBPAa9D+Sm6OtkFhNsOtLMOW/HuirsaZVTCtkhZ9 L30Y95gTNcUfg0YOIl0V5qDTnNQPnPJzRhfR3uN1+DBSZWepEbX8W0AS8j5vPsmk bpjGp72pHWkml5Pk/DQK3vUUYY/AezC2a1T+CNP/8PcXIVh1aQcQmcc6DdTzARv5 Nz2PggbWSVnpCuINZtBPPctlhumUqmFaKKSTi+nrclIjryUiDc+wixirh/rAsXXt pO8RGT6OPAMa5U0UiartBA7q8g4GEXr31UKRLrKSN8VlB4Lg54LQlOHuTslKB+CM MNzxMGn1EHXDjU7AqVaCwU0pYanIO3X4uRgSdJrVhl64KVOKwWCzFrU6gubfzo6m fUpubqqJ3oPEahN3+7zIoVPfH+S6+6hV4i3W5d02yfuC+EDVRPU= =beo+ -----END PGP SIGNATURE----- --6mHsfCphvs371pEX--