Re: [PATCH v1] xstrtol: Remove dead code

Alejandro Colomar <[email protected]> Fri, 19 Jul 2024 01:21:31 +0200
Newsgroups dev.linux.lists.liba2i
Message-ID <dpytrfxb2726ygcqu5uveuq72dm4shs3ali6ul3a4bqrilhepu@kfhckv3435zb>
--qt4yfyjbeydnrutt
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], Michael Vetter <[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]>, [email protected]
Subject: Re: [PATCH v1] xstrtol: Remove dead code
References: <[email protected]>
 <8009158.qOBuL9xsDt@nimes>
 <kul6qwyrvq2xdevjjkkblsalg7ycwg6x7ey725kans5myqjcai@3jm56c5famlt>
 <1937032.gKo4GoxMFQ@nimes>
MIME-Version: 1.0
In-Reply-To: <1937032.gKo4GoxMFQ@nimes>

Hi Bruno,

On Fri, Jul 19, 2024 at 12:34:39AM GMT, Bruno Haible wrote:
> Alejandro Colomar wrote:
> > >   - 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 implemen=
tations
> > >     of strtod() do use malloc().
> > >=20
> > > So, what you call "dead code", I call "defensive programming". I woul=
d not
> > > like to apply this patch.
> >=20
> > Makes sense.  I think we should document that possibility in the manual
> > page.
>=20
> Well, I wouldn't want to document just _theoretical_ platforms.

While it may be theoretical for strtol(3), you said it was real for
strtod(3), and strtod(3) defers to strtol(3) for the example program.

We should provide a portable example of use of strtod(3), and rather
than writing another example for strtod(3), maybe we could improve the
strtol(3) one for theoretical implementations.


> The set of
> manual pages has a certain scope, regarding platform, probably Linux
> (and Hurd, maybe?). It's the behaviour on these platforms which should
> be documented, nothing more, nothing less.

Not really.  We do document portability to other Unix systems.  Mainly
the BSDs, but in some important cases we document others.

>=20
> Defensive programming means to imagine other behaviours that could
> possibly occur. It is subjective; some programmers want to be more cautio=
us
> than others.
>=20
> > Maybe say that other errno values are possible in some systems?
>=20
> Other errno values are always possible, as far as I understand POSIX.
> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap01.htm=
l>
> section 1.2 ERRORS.

True.

> It would be overkill to state this in hundreds of manual pages, IMO.

strtol(3) is special-enough regarding errors, that it might make sense.
Even if we don't mention it in ERRORS, it would make sense to fix the
example program to make it portable.

>=20
> Bruno

Have a lovely night!
Alex

--=20
<https://www.alejandro-colomar.es/>

--qt4yfyjbeydnrutt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmaZo3sACgkQnowa+77/
2zLShw/+Kx2MpUaeLfyreKi2KE+Pp9o2oWLBXeMDyaVzQIKfoT0l5aBmicJpSZms
5U/WEVaQYlTMQZb/STGEtW7XPS47V5pjxj3vw+xsk22Y8MX8M5GsqaldOE6NmyKu
ds+NdpbCxokSpfP331F5EnH1YM41a3gIX4TeirK9hSGPqc8CSAjiGtuXch6A2RI3
DNqI2RQsy6Y8LuZHiuz7TuFgfaIlmxaQELHpfVq6J8pQjguH2fPn+NDiW0JntJSM
x4oBp4uzlHZZoat3sRKJG2ADlzlsgmdXBWd6i3UNKJb+uFyYzV7vmDzcU/y+xXCV
Jg5VlAPKowIwISYcR4Agzlp1vWlbup9D0IEMpmJiiHHv0X7BIBlwyki/lNQUuLpQ
1qObtLm8GuqWn16H1nVGU8zUpfaoFoySxRa3ZsdnZLpH9X94+dGwNyCyCXnONIHD
r+bCqnb5B4gvVv5DE1nQYXk5WRsVCE/5n+C1AvQG0lhiNIJK8GH17p0u7i+/JEnP
rW/aSHcmK4qh4POdCu5O4U7TRu4t2V3+x3YshdzAYw3+dWmCAsDntSrbgu/D94Cv
Y/eoLA2CDfMcPIhcPN6d98SbG3rDKLY9y+qun34KYRBVgY5en9YZpBAD9LFgHpNd
7tG3PElPBqh849gEj/YPeDUEOWJ5q4WM8LYWII8Q+yWpiSK+IxE=
=SmRk
-----END PGP SIGNATURE-----

--qt4yfyjbeydnrutt--