Re: [PATCH v1] xstrtol: Remove dead code
Alejandro Colomar <[email protected]> Thu, 18 Jul 2024 23:25:07 +0200
| Newsgroups | dev.linux.lists.liba2i |
|---|---|
| Message-ID | <kul6qwyrvq2xdevjjkkblsalg7ycwg6x7ey725kans5myqjcai@3jm56c5famlt> |
--55tbl4jcbtrojuzf Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar <[email protected]> To: Bruno Haible <[email protected]> Cc: [email protected], Paul Eggert <[email protected]>, =?utf-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZw==?= Danh <[email protected]>, Eli Schwartz <[email protected]>, Sam James <[email protected]>, Serge Hallyn <[email protected]>, Iker Pedrosa <[email protected]>, "Andrew J. Hesford" <[email protected]>, Michael Vetter <[email protected]>, [email protected] Subject: Re: [PATCH v1] xstrtol: Remove dead code References: <[email protected]> <8009158.qOBuL9xsDt@nimes> MIME-Version: 1.0 In-Reply-To: <8009158.qOBuL9xsDt@nimes> On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote: > Hi Alejandro, Hi Bruno, > > strtol(3) has a limited set of possible states: > > ... > > The condition '*endp !=3D s && errno !=3D 0 && errno !=3D ERANGE' is > > unreachable. The only errno possible if '*endp !=3D s' is ERANGE. >=20 > Such a statement can be true if you look at the standards (ISO C, POSIX). >=20 > However, there's a difference between what the standards say and what the > systems actually do. The Gnulib documentation contains thousands of examp= les > of such differences. >=20 > Gnulib therefore (almost) never assumes that there are no possible errno > values besides the ones listed in the standards. > - Some systems return "wrong" errno values. Example: [1] > - Some systems fail with ENOMEM when memory is tight. Who says that > an implementation of strtol() cannot use malloc() ? Some implementati= ons > of strtod() do use malloc(). >=20 > So, what you call "dead code", I call "defensive programming". I would not > like to apply this patch. Makes sense. I think we should document that possibility in the manual page. Maybe say that other errno values are possible in some systems? Otherwise, it's already a hell of a function to take care of, and most uses don't handle that possibility at the moment. (Yet more reasons to use a wrapper that returns -1 & sets errno on error, as the rest of libc.) Would you send a patch? (I'd write it myself, but you probably can provide more info in the commit message.) Have a lovely night! Alex >=20 > Bruno >=20 > [1] https://www.gnu.org/software/gnulib/manual/html_node/getlogin_005fr.h= tml >=20 >=20 >=20 --=20 <https://www.alejandro-colomar.es/> --55tbl4jcbtrojuzf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmaZiDIACgkQnowa+77/ 2zIP9hAAoEMbf7jnC275hd6dtBg1rLF2IP0L2ugxEcYG2fjVXE1ZJSUUd8GeKUhq HTQ3VK3yjhztKiyEYqMV9hc2bc9zHot9f9zqsq1ZJk0XtiZaRIncruLFFJjKny1S YjZWBreVSpmcwIBR5SKOwCDFAra2RPOQreUZ2WxAkdcFIbdQf6JF3S8X/fnVsBWW G5Olh+MUaetnLAzTDNdBE5Nb9klv2CrGusae7GCmSJmcgDaVeVbH66DyXjzqJgaG 8G9f/7AY8IO6Y2Z/gsigtV27WKDJmbw0LmTKHOaV5lT6+DP+eXjqkop2leLYWGAk DqcJUYPAGuGf8Sa2fJIZPnr/7Vpsp+zy82ryTlt1heYJXk04HZ/X2klYSQiV87A1 jtyfAVxZfVVA6rZTkB19p1YAjXsjTquFwi+1X8jsGXPchyo1X9EMO+bx/1USKBxg oIqguPvD0uqpEDeUH71LgegrBh0nK+qXFF7I1sZo8kv2u6lVlNT41R2qPdU60GDz /zZSp+E/XQ1aBq5u1z9RnLFWovdIoWFHTBw/ocmXi5AIKrCLTmbzX7xbpr2jisG4 hQrEanmQGVLnHcyQQ4/9kZwWTK2UaYS2H3LB1ngvcz3Qo2o1X1nMU1qTTLt4mohQ CroY7Jcz7OXaB0l6V4IO8ojJv2BrStpRpPQzLWkU0FQlmWjOKDw= =0Xcq -----END PGP SIGNATURE----- --55tbl4jcbtrojuzf--