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--