Re: [SC22WG14.29912] alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD

--jpgwjjyrx32us3wq
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: Joseph Myers <[email protected]>
Cc: Alejandro Colomar <[email protected]>, [email protected], 
	[email protected], [email protected], [email protected], 
	Bruno Haible <[email protected]>, christos <[email protected]>, 
	=?utf-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZw==?= Danh <[email protected]>, Paul Eggert <[email protected]>, 
	Eli Schwartz <[email protected]>, Guillem Jover <[email protected]>, 
	Iker Pedrosa <[email protected]>, Michael Vetter <[email protected]>, Robert Elz <[email protected]>, 
	[email protected], Sam James <[email protected]>, "Serge E. Hallyn" <[email protected]>
Subject: Re: [SC22WG14.29912] alx-0008 - Standardize strtoi(3) and strtou(3)
 from NetBSD
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <hndqaew5q2ymvbznl2rb6rwimt3y355udehg7ulvhax6gfvfjk@vdycrv2ym2mg>
MIME-Version: 1.0
In-Reply-To: <hndqaew5q2ymvbznl2rb6rwimt3y355udehg7ulvhax6gfvfjk@vdycrv2ym2mg>

On Tue, Mar 18, 2025 at 10:35:53PM +0100, Alejandro Colomar wrote:
> Hi Joseph,
>=20
> On Tue, Mar 18, 2025 at 09:11:58PM +0000, Joseph Myers wrote:
> > > > >     7.24.2  Numeric conversion functions
> > > > > 	New section _before_ 7.24.2.2 (The atof function).
> > > >=20
> > > > You're missing corresponding <wchar.h> functions.
> > >=20
> > > As with other proposals, I prefer leaving it for a different paper.
> > > I'm not an expert in wchar stuff.
> >=20
> > I strongly disapprove of this approach to making standard proposals; if=
=20
> > everyone does this, it's a recipe for turning the standard into an=20
> > inconsistent, non-orthogonal mess, where each feature only has sensible=
=20
> > interactions with the subset of other features the proposer of the new=
=20
> > feature was interested in at the time they added it.
> >=20
> > As far as I'm concerned, it's the responsibility of the person making a=
=20
> > proposal to produce a complete proposal with properly orthogonal=20
> > interaction with other features.  I objected to the unsuccessful attemp=
t=20
> > to define complex literals that didn't allow for Annex H types, and I=
=20
> > object likewise to randomly proposing functions, for a family that has=
=20
> > corresponding <wchar.h> functions, without the corresponding <wchar.h>=
=20
> > versions.  If a proposal is to add some non-orthogonal feature, there=
=20
> > needs to be a good and clearly stated reason why, *as part of the overa=
ll=20
> > language and library design*, it makes sense that way.  That is, not=20
> > something relating to your interest or expertise in <wchar.h> functions=
,=20
> > but something about the technical content of the standard that makes=20
> > having some strto* functions with corresponding wcsto* functions and th=
ese=20
> > ones without corresponding wcsto* functions into a logically coherent=
=20
> > design.
>=20
> Okay, let's try with some more rationale:
>=20
> NetBSD has strtoi/u(3), but not wcstoi/u(3), AFAICS.  This is prior art.
>=20
> I don't feel qualified to propose a function for a family (wchar.h)
> which I have never used myself, nor implemented.
>=20
> I think it would make sense to present two papers at the same time, one
> proposing the wchar.h variant, and one presenting the normal variant.  I
> just don't feel qualified to decide whether we want a wchar_t variant,
> nor to specify it myself.
>=20
> On the other hand, I feel qualified to propose strtoi/u(3), and think it
> is quite necessary in the standard, regardless of what happens to the
> wchar_t variant.
>=20
> If someone who is an expert in wide strings wants to work with me on the
> specification of a wide variant, I'm happy to help.  But I can't do that
> myself alone.
>=20
> > (I don't care about Annex K myself - but I still made sure that my rece=
nt=20
> > report of issue 1012 included the relevant Annex K edits.)
> >=20
> > > > I'm also concerned that the names sound like int / unsigned int ana=
logues=20
> > > > of strtol, but aren't.
> > >=20
> > > I don't get to choose the name.  Anyway, my plans are to erradicate
> >=20
> > You do get to choose the name when making a new proposal.  If an existi=
ng=20
> > name is defective through suggesting an incorrect analogy, that would b=
e a=20
> > reasonable basis to choose a new one.
>=20
> Yeah, I could choose it, if I had a better one.  I did that for the
> case of Plan9's seprint(2), which I called aprintf().  However, in this

s/seprint/smprint/

> case, I don't have an idea for a significantly better name, and
> considering that the number of arguments makes accidents impossible,
> there aren't strong reasons to deviate from prior art.
>=20
>=20
> Have a lovely night!
> Alex
>=20
> --=20
> <https://www.alejandro-colomar.es/>



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

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

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

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmfZ6FsACgkQ64mZXMKQ
wqnxwQ/7B+34uqIymeT/uBx1ygeZZVOtgHf8S6xdZgzrdWfOQheFZP1B9AkWh8kw
L6LuWT7e1V5NeOw9s7MkKIQDKVkOSHad+Hm3GxrZoGdSU3/Aqckhusmh9XhkTprq
mluVB+LDC9oj7TU6uyF3+37QMQt/vr99j9KtaFzR7MbFi8nO02UKYW1mbGSuzCSe
hBrBxp8D20uIu7G10CiFtETY+N4mE3Y+XGfhM2uQv6b5J7qYds+603CRrGZL7t9V
DwFYgeL+eN/CjsvQa/26uT4k+uT71o/qAylTJI+KC+LNHBPXKXJByJtSqRVLQz8E
7pAjNvcRa6Qr7yBZK2mtVmw4X7WAjhs+Lu+OguooWAZTWrsNZJz43+xGSyxIVL4T
7HKNR5qnS1pvnc0gJ0BJHRDD8zQnnodlyj0OGvGqw5xsrXIXhxW3U1Q0dtY2f1Ed
FZmEgJ+Tbo47pPpXQleHiZkN8ebqq1VbwJDa4xyTYY1A9u6KUD0xNiJyP1E3Q7Nf
FkbpoPBEFHLCtNIs+h8R9CErwEULwXa2DB20buak1yauq7u6MHRWJTjuTBn2Q5b9
dorCLD7RTlByhAzsauBbL4sK9lCKyK/NJOoqCX88mLWu4krJp8kinkN/kXDFwF60
sA7w4nMk3oK4IF4bVgo0hNxcdSqVC4Ly/CDpYGTkwl9QgfWQVy4=
=NN00
-----END PGP SIGNATURE-----

--jpgwjjyrx32us3wq--