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 8BC413858C98 for ; Sat, 2 Dec 2023 12:34:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8BC413858C98 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 8BC413858C98 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=1701520457; cv=none; b=kCr5jRn4xnOrGDA1mZ/q67Tj+558cb2CPz5BWSpFyeFC9NR271NQkfAq53XA3NQQN6hycYhTrxgoxtpDvTgsgz2NK1QS35HfXN6YSJHRIeGfRnJBQ2/eVrEXQ9zYnwd1zIOZyFsUnwyRC/HTLydHF4q6dFoARYrswcaVnLlPgdg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701520457; c=relaxed/simple; bh=8IYzyHGwaeTWjcHu+7MF+acPwRJ/4xB2qyrZITVpMMU=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=P7Z/uPMHGvp9yjwhaEstI/5BU+bg3VpUHAiDjh71jR9RXTBkpCk3wGtWFq0xrjfT/UVftZp/Yd33Wp3nlqxjsXbSYg8rDSePXilnnKvuqkFJXzoR3pKtox5/a27U3NKSUIlojvMv/wDZiipp8zAy1Gy4Tti9B3ApdXSRO9AiNsM= 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 6EB63CE0B09; Sat, 2 Dec 2023 12:34:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A53A6C433C8; Sat, 2 Dec 2023 12:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701520449; bh=8IYzyHGwaeTWjcHu+7MF+acPwRJ/4xB2qyrZITVpMMU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A5QZIShpEqlG7QZ0iVrWlk0WlSgqBAa1xXLpt9+RUEUENjLWJrUj74R8BMj3q9XBg 68A4RaHSr3b4DPL6CTXeJYg3jnUgFiTgS3ay/2EZQJpdCMPnHmdnYqTdMMXnT474ay u9mOcKKgacwQgL7++gSY1WG0A9yJKAWxgtcgOLurxhiuixDTAGwGE5sP1W4/CS+ixq IHYH7imSda3/32oVHTWXr71sRu24ZYCyql3pMChc/AnMUwCjy6Ldq0DNM9Yv7tkJX9 Is/wo/HCob90kDiDKBTspbbu4KmIZ2WUdu3AMw6C+fiA18wGzM5og45f0wW/upVaJ9 LSEQ/I7XlOIDg== Date: Sat, 2 Dec 2023 13:34:06 +0100 From: Alejandro Colomar To: libc-help@sourceware.org, gcc-help@gcc.gnu.org Cc: 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="anVDTcPLS9Dpw7ge" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.1 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=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --anVDTcPLS9Dpw7ge Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Dec 2023 13:34:06 +0100 From: Alejandro Colomar To: libc-help@sourceware.org, gcc-help@gcc.gnu.org Cc: Guillem Jover , libbsd@lists.freedesktop.org Subject: Re: restrictness of strtoi(3bsd) and strtol(3) On Sat, Dec 02, 2023 at 01:29:01PM +0100, Alejandro Colomar wrote: > On Sat, Dec 02, 2023 at 12:50:28PM +0100, Alejandro Colomar wrote: > > Hi, > >=20 > > I've been implementing my own copy of strto[iu](3bsd), to avoid the > > complexity of calling strtol(3) et al. In the process, I've noticed > > that all of these functions use restrict for their parameters. > >=20 > > Why do these functions use restrict? While the second parameter is not > > used for accessing nptr memory (**endptr is not accessed), it can point > > to the same memory. Here is an example of how these functions can have > > pointers to the same memory in the two arguments. > >=20 > > l =3D strtol(p, &p, 0); > >=20 > > The use of restrict in the prototype of the function could result in > > compiler warnings, no? Currently, I don't see any warnings, but I > > suspect the compiler could complain, since the same memory is available > > to the function via two different arguments (albeit with a different > > number of references). > >=20 > > The use of restrict in the definition of the function doesn't help the > > optimizer, since it already knows that the second parameter is out-only, > > so even if it weren't restrict, the only way to access memory is via the > > first parameter. >=20 > In the case of strto[iu](3bsd), I have even more doubts. >=20 > Here's libbsd's version of it (omitting unimportant parts): >=20 > $ grepc -tfd strtoi . > ./src/strtoi.c:intmax_t > strtoi(const char *__restrict nptr, > char **__restrict endptr, int base, > intmax_t lo, intmax_t hi, int *rstatus) > { > ... >=20 > im =3D strtoimax(nptr, endptr, base); >=20 > *rstatus =3D errno; > errno =3D serrno; >=20 > if (*rstatus =3D=3D 0) { > /* No digits were found */ > if (nptr =3D=3D *endptr) > *rstatus =3D ECANCELED; > /* There are further characters after number */ > else if (**endptr !=3D '\0') > *rstatus =3D ENOTSUP; > } >=20 > ... >=20 > return im; > } >=20 > Let's say the base is unsupported (e.g., -42), and endptr initially > points to nptr-1. Imagine this call: >=20 > i =3D strtoimax(p + 1, &p, -42); >=20 > ISO C doesn't specify what happens if the base is not between 0 and 36, > so the behavior is probably undefined in ISO C. >=20 > POSIX says it returns 0 and sets errno to EINVAL, but doesn't say what > happens to endptr. I expect two possible implementations: >=20 > - Leave endptr untouched. > - Set *endptr =3D nptr. >=20 > Let's suppose it leaves endptr untouched (otherwise, it would be > impossible to portably differentiate an EINVAL due to unsupported base > from an EINVAL due to no digits in the string). >=20 > So, the test (nptr =3D=3D *endptr) would be false (because p+1 !=3D p), a= nd > the code would jump into accessing **endptr without having derived > that pointer from nptr, which is a violation of restrict. Oops, it's within an (errno =3D=3D 0) path, so *endptr is guaranteed to be derived from nptr here. So no bug, but still unclear to me what's the benefit of using restrict, and also unclear why GCC doesn't warn about it at call site. > I made many assumptions here, where the standards are not clear, so I > may be wrong in some of them. But it looks to me like a bug. >=20 > CCing libbsd. >=20 > Cheers, > Alex >=20 > --=20 > --=20 --anVDTcPLS9Dpw7ge Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmVrJD4ACgkQnowa+77/ 2zJZgg/9FiYOBRK6aDXtFTfTx17s2284Fo+N1HK/5sFTlFqRDj7wZcsXbMIHHE// zzAlDyweYHmHftgjEtfobx/4rUk1yGq7ptwsbXNjl9lpWolTY+BlIfVXNy84LmK+ 7p6fWqdY7MtzjI+aEp/mmkXlvQJp1DDnR/QK9CvkG795KadTGJNfPZxFQ3uzs15A qN1TmF+nOlurQPiKKrUKyeX121mahj2W1n6vagI2JNfLxLjYzbl79ZRoDDjBteYy LOB25uIUW+A9i56wu5dIeRPtnoyUgj6T9j1OJko7q4ZG4HtyfsVtM1X/MbnboA7m hHP4h3C6Rb5EJ1049Ffr8oy3QOsYjVx6jvENUOEIuUl/+7em4+cGs9H3Sw5DeZhA fJAFkEiGfr+Ti8YKIrzOLCU6KocV9iftT8iPMzKV4Enyty1q9sCLv7VweD/3iLvS gtMOnTLyYe+/MAfW84fwN30AqTBeSfiUz7NjZUSY7y4qeNwvA78EjZR8MhFIGGkM /Iduvnq+LUS3uFxdf3YNDbXRBC5T2D5owR146zY97ZhXPfDCHRoFzO15jKZOqXLG bB8wOXb5YqeEfnwkJXcddEKgKbu+TtRFjF2gNlHJDsZd3f7Cnsxi+GR6dPXSZAqW SjuYwXhnUPNMPv7M97rA/VEfoYKE+wZBq0HLI1jlxbvEdpFgTTE= =EuZg -----END PGP SIGNATURE----- --anVDTcPLS9Dpw7ge--