From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by sourceware.org (Postfix) with ESMTPS id 38D6B3858C98 for ; Sat, 2 Dec 2023 12:29:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38D6B3858C98 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 38D6B3858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2604:1380:4601:e00::1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701520155; cv=none; b=TVCBF2OKeGHV+kb1dVEfUcsqXJcSGyu0oxlmkIf/GZd9NqlsPjvNXgyYQ8V1jZ8Plly1fhpmaYMLr5Ih1BWSfWOGH6TEWI3qdcum/PllFBmbWMPnRoPSVDc1wJdzZviP2vqPWaaY8Y4OnICJD9UUGamGu6B8vg76Y8wnpW0Dp40= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701520155; c=relaxed/simple; bh=tPS/QdApveTSyhA0Ufl4gXNeEoZFh1Fht05M1b8Y9oY=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=XJHJ6TRbm29ETjq/XUGr6rYrkN6O1GH4bsSuCFhNqB8pyXk+4bhK08hdw2cF57I1EUWWyeQfH5QCl4uCPRhvlmP2kbY6/HbFSVBxw4e1em8l4kTqPMKkA+Q0VPgIT07TZBkS3eNbp5f0G3DL5duHnYBqjhoLNRw0rZ2Lvzts5GU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 8641FB8406C; Sat, 2 Dec 2023 12:29:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2534AC433C9; Sat, 2 Dec 2023 12:29:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701520151; bh=tPS/QdApveTSyhA0Ufl4gXNeEoZFh1Fht05M1b8Y9oY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fuddP0Y7Cgsa+kKUbx/ww+ReTHpEuRBMNoVE29/f/DqUJrria/SEJkCzN+83bnOaS fcF0u5sJHNkOx7L2q0Mpop5bpcWqYmroULzONQHui8i1O99RVaXzEjTpdfDHkM0LiU 3zvragm2Xkw1z79UdeeZZSznLNHxVszv0WMbnMAAoZiPi+bq7NFx32MWPRFiFmKKYW 8CuGye9agPDufTxcdt/kov+uNhcYqJ6vH4XyL5eeVhcYIdxvCbV4o0HHbmV8hylT6+ 5WiYlUpnxSP58Am22T/7trCii8/nFgpX+jR76QyGIZgeeQCebvHI4vNCWwRZCxYKHu lVcfRk4GzJcZw== Date: Sat, 2 Dec 2023 13:29:01 +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="ivrSdX65ATm5fcG4" 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=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: --ivrSdX65ATm5fcG4 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Dec 2023 13:29:01 +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 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. In the case of strto[iu](3bsd), I have even more doubts. Here's libbsd's version of it (omitting unimportant parts): $ 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) { ... im =3D strtoimax(nptr, endptr, base); *rstatus =3D errno; errno =3D serrno; 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; } ... return im; } Let's say the base is unsupported (e.g., -42), and endptr initially points to nptr-1. Imagine this call: i =3D strtoimax(p + 1, &p, -42); 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. POSIX says it returns 0 and sets errno to EINVAL, but doesn't say what happens to endptr. I expect two possible implementations: - Leave endptr untouched. - Set *endptr =3D nptr. Let's suppose it leaves endptr untouched (otherwise, it would be impossible to portably differentiate an EINVAL due to unsupported base =66rom an EINVAL due to no digits in the string). So, the test (nptr =3D=3D *endptr) would be false (because p+1 !=3D p), and the code would jump into accessing **endptr without having derived that pointer from nptr, which is a violation of restrict. 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. CCing libbsd. Cheers, Alex --=20 --ivrSdX65ATm5fcG4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmVrIw0ACgkQnowa+77/ 2zI79w/+JqRFkpSwiy417ZNqnzY9y66HQ0grPeiYQ5ZDIHwE+EMQyn57OrXKkK0D 7Pjbd3eJhz81tikUVig7WqCUtGAnnHwxcu5oyLOcDEnCjagA6JORTTnqTQGwlRur dhuZIqMzz1iWzO8qKgV2U19FTr2cuPKA0RpsC3+syS06Q83sICEsXAKKsUv0qxXE UnJ2wRQTlrqGfuFfvvW6+0TUVBj+DWIHZIK36Hvl3HS2TYTXeDZoVLWx1nm+EIOr Np8BCkeZATWUVmGjRKSaywuKKVdyXWuFoC/vU8ZAdHfemIjKHiLdRY+6WWDCP/Sw d+C4YNZB5bGRJUtZj4nNVy4D9YsLOs83UtPBQuxLm+LPZgKenSm8Wdje5u4poJMe vUJp8H0fF+C89X2EnzUjORaec2SK6BDJLSSujGUrLHTMSV3cndzaxyapdbmYNoDD Zs20FBhIAkeJ1A0gp6GP9h/cmY3H3JQWQHdVGQRswulT8wd3elFSlBwBpzMQSSTg kP8FBVU6nxeOW2K7qqFEo0iB/vU1Phc2BCoalx8xNvag5T3yuPpSOv7NziWjKnW5 nhEeJ5sC6JugtIvpwHu7AWfhqnUFdvgllKOMcDnZF7/9JyC5jEPppYlsjZTkfLL3 NPMjuNbbqPXryQLlnXpg2ycm2L5C8Ce8aKWX0AP0Rap6omt0C4I= =Sjyl -----END PGP SIGNATURE----- --ivrSdX65ATm5fcG4--