From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 580D71B95B for ; Wed, 19 Mar 2025 00:16:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=85.215.255.53 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742343387; cv=pass; b=q9VpudMwZNvjKqf+RU99u3mW5izHGY7/UpaIyDp5vqBbB37wEC2Advd54Rrn10MPym0axGOCeQ7aUepGIXsYN6zTVT5MgRik03OOEmWhrNAEvETkHYYo/lXuW/3FiofUZZj5STg2S3cZSDpTXBh1FuhhRaMR1S6Xt45gEH4KnYo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742343387; c=relaxed/simple; bh=llwKGsi35mfJCaMDxYbIim2d4HoZuklVI2M7olBG1D8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=CUp5wyLO/hLig7cETNJoFrd3pBzxTDIkwrV+pLqJtq6AXHzdwqu3TLpP4wBgPNFCKQZ0CyhS4y0Pa/i8gGsno+ngQ9EZ9BnZ8lyZdutYxQ5HmfXTR5mEF4tTtmJ9hkTZROCu2KkoBBQn1z7QOoeRklYvZFdR4RX7DTcNStf/9bQ= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=clisp.org; spf=none smtp.mailfrom=clisp.org; dkim=pass (2048-bit key) header.d=clisp.org header.i=@clisp.org header.b=azebWIUT; dkim=permerror (0-bit key) header.d=clisp.org header.i=@clisp.org header.b=opYlUn/X; arc=pass smtp.client-ip=85.215.255.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=clisp.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=clisp.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=clisp.org header.i=@clisp.org header.b="azebWIUT"; dkim=permerror (0-bit key) header.d=clisp.org header.i=@clisp.org header.b="opYlUn/X" ARC-Seal: i=1; a=rsa-sha256; t=1742343332; cv=none; d=strato.com; s=strato-dkim-0002; b=CUjAAhnLsjM0ylsmw5hGx/0to/7SgDeAKZxQFD4bFi2i8htkH/X4rjRu6hRIMFkTmE ECZPIj7Gfv683S6SECPhNLqy6XAhPD/9agmlfqDDuAZ5G6vJyWlJPKPHYHNhCnkgS7KX ZmCFpY5cWxsrblBS3M3lPAl6LemL1wv4dqkyiP9PT32NfHz43VpKUTA3PYQZtZ2U/JNB 7KgUJUl45tltloZoAUhjEPGNoUHaW6xlxIBhSi4T/E7s0Fnl8VFijxhBnKlaBDdJBIqe sLIC2f4kYILcwS7Mpcq3OX/SgIsZvU0g/HBSVn8Re4U4CPCuFZHx0JbJYQItuJMAIYAE 4HlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1742343332; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=XFibXw1nTU9ebsNEaer4lrSZ7whiYRUo9RWcXtvOqMk=; b=iORNMZHcimR5/5Hd80rOUq2NPb5XF7wfLroPgTkfIc9t52N6Mm5PaXlVvyt37/xdzl CQ592YRsLDEW5M+cBt84FghMK6t0SJbRABCWznYjn8+kzrNJEIOhHyKDl8V4AQQZHJyi DwuhBfSMc2Im81gusTjrzJ2XdNlomQ/5SUmYlOMI0fSha4IBY90AbCgICyHWYi4PGOi1 IDYXjci1STx43VWy9mIN3RDT6Zxh4M6oTvJZFpVQa8Kia5FJ1svaTSnf38z7EteI+NqJ VujGz9APVHEouvj0wBNE9qebyAT5Xi9OLFMhDA26x9zy8z2aDUQXs8CEpN/XMS1KA/IV mYbQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1742343332; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=XFibXw1nTU9ebsNEaer4lrSZ7whiYRUo9RWcXtvOqMk=; b=azebWIUTg8psfziMm1TsH+kxpN+oCieI6M8/SaOJbAWEIOE4vz0RFnUEfDuSe4sNrF mADGKeIMhmjesCRdZWQ0k4YQHdXyo3++8Hxvaa4DQ0+ewsAAWM6enpj97oPyk5z5irE5 ZavvU6hoywOUH4uOgtQ8fMAlg48q1SHtoR4TK8hSZ0cvaZkFZ0bug5XtWWvKgbZrohpV Ceh4hUVA/xItxZ9hQVppti7jo4K57A9rC9lJ2PsTnoyo6ToDjSs8I0T0QCA3IYLjgwPm 2+n7oS3fI2L02Nx37ehgHot4LE945rYFxn/EIGYedntMrpczRS+zLhx2ESzIwZmaKbOi A6zA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1742343332; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=XFibXw1nTU9ebsNEaer4lrSZ7whiYRUo9RWcXtvOqMk=; b=opYlUn/X2VGRrGTdntBUKrj6Mu7ol8y4C7V1D7TUbIFqb9qH8uQjV7e4uN4kToJxKS d88BGOWOr5Akuc3+dBDQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlLnY4jECd2hdUURIbZgL8PX2QiTuZ3cdB8X/nqmqYEWkN6DGVKOEnUurE7fG/J+o=" Received: from nimes.localnet by smtp.strato.de (RZmta 51.3.0 AUTH) with ESMTPSA id N7dcf812J0FU3aL (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 19 Mar 2025 01:15:30 +0100 (CET) From: Bruno Haible To: Alejandro Colomar Cc: liba2i@lists.linux.dev, sc22wg14@open-std.org, libbsd@lists.freedesktop.org, tech-misc@netbsd.org, christos , =?utf-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZw==?= Danh , Paul Eggert , Eli Schwartz , Guillem Jover , Iker Pedrosa , Michael Vetter , Robert Elz , riastradh@netbsd.org, Sam James , "Serge E. Hallyn" Subject: Re: alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD Date: Wed, 19 Mar 2025 01:15:30 +0100 Message-ID: <3237498.fEcJ0Lxnt5@nimes> Organization: GNU In-Reply-To: References: <18739733.sWSEgdgrri@nimes> Precedence: bulk X-Mailing-List: liba2i@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Alejandro Colomar wrote: > > It would be useful to show how a success test looks like, after > > strtoi (s, &end, base, min, max, &status) > > for each of the four frequent use-cases: > > -a. expect to parse the initial portion of the string, no coercion, > > -b. expect to parse the initial portion of the string, silent coercion, > > -c. expect to parse the entire string, no coercion, > > -d. expect to parse the entire string, silent coercion. > > > > AFAICS, the success tests are: > > -a. status == 0 || status == ENOTSUP > > Correct. > > > -b. status == 0 || status == ENOTSUP || status == ERANGE > > Correct (but most likely a bug). > > > -c. status == 0 > > Correct. > > > -d. status == 0 || (status == ERANGE && end > s && *end == '\0') > > You don't need end>s, because that would preclude ERANGE. > > status == 0 || (status == ERANGE && end == '\0') > > Aaand, most likely a bug. Cases b. and d. are not bugs. Often, the programmer knows that treating a value > ULONG_MAX is equivalent to treating the value ULONG_MAX. These are *normal* uses of strto[u]l[l]. Often it is the programmer's intent that the values "4294967297" and "4294967295" produce the same behaviour (the same error message, for example). It is for these cases that your specification contains the clamping / coercion behaviour. Now, when you look at the table of success tests: -a. status == 0 || status == ENOTSUP -b. status == 0 || status == ENOTSUP || status == ERANGE -c. status == 0 -d. status == 0 || (status == ERANGE && *end == '\0') it is immediately clear that the status return convention is ill-designed, because the returned 'status' is not the only thing a programmer has to test after calling the function. > Cases b and d are not real, IMO. I have never seen code where that is > wanted, AFAIR, and I analyzed the entire Debian and NetBSD code bases > looking precisely for that usage. I disagree. Any use of strtoul that does not test errno wants overflow to be mapped to ULONG_MAX, that is, is in case b. or d. Just looking in gnulib and gettext, I find already 6 occurrences: gnulib/lib/getaddrinfo.c:299 gnulib/lib/nproc.c:402 gnulib/lib/omp-init.c:48 gettext/gettext-tools/src/msgfmt.c:287 gettext/gettext-tools/src/msgl-check.c:379 gettext/gettext-tools/src/read-stringtable.c:561 > > I would therefore propose to change the status value to a bit mask, so that > > the error conditions "The converted value was out of range and has been > > coerced" and "The given string contains characters that did not get converted" > > can be both returned together, without conflicting. > > Because it is theoretical conditions that a real program never wants, > let's not do that. If you don't want to do that, I can only repeat what I said in the previous mail: The proposal *does not achieve the goal* of avoiding the most common programmer mistakes. For a robust API, the success test should *only* involve testing the returned 'status', nothing else. Bruno