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

--enhac5oladjw6qms
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>
 <[email protected]>
MIME-Version: 1.0
In-Reply-To: <[email protected]>

Hi Joseph,

On Tue, Mar 18, 2025 at 10:14:03PM +0000, Joseph Myers wrote:
> On Tue, 18 Mar 2025, Alejandro Colomar wrote:
>=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
> Prior art is something to learn from, but if there are issues with it (an=
d=20
> not being properly orthogonal when considered together with the existing=
=20
> APIs in the standard is such an issue) then they provide a basis for not=
=20
> adopting it exactly as-is.
>=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
> This really doesn't need much expertise.  Just look at how strtol and=20
> wcstol differ (such as references to "wide character" for wcstol) and=20
> follow that.  I think that by the time the proposal reaches an actual=20
> document submitted to the committee, it should include both wide and=20
> narrow versions (even if earlier drafts just state that the wide version=
=20
> will be included in the full proposal, but omit it to reduce the extent t=
o=20
> which changes need applying to both halves of the proposal, while it's=20
> still changing rapidly).

Okay, I'll include a paragraph saying "a wide variant will be added to
the final proposal".

I still want to submit an N document without it, to allow reviewers to
concentrate on just the API concepts.  Then, well before Pittsburgh/Brno
I'll add the other one.

I hereby disclaim any mistakes in that part, and encourage anyone
interested in having (or not having) it to verify it thoroughly, and
express it as soon as possible.

> It's *excluding* the wchar_t version that would need more expertise to=20
> justify any such exclusion, because the default for these interfaces is t=
o=20
> have both versions.


Cheers,
Alex

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

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

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

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmfZ+IIACgkQ64mZXMKQ
wqk3hg/9E7s4ZmdTmDLkaKSgSGk6j05mqrraSNnjhrv4MUNKXOv7Ky7iEXbnh5Sc
pbyhvhlLc4rZ1TibBEj62Da3glMrwhP0AkogYjhbDdJqcMt19Qz2FEP+7IOIff9s
70ByA2DuWZHm47+BeOYxGwcGYYFMGffkuBONP9ShPKdTlDfeuZp0kafhlLuDu7YY
aHHq0PM56/CuCAEtW6DqBkUhGzRaUyvDyQDY3wiciGYnGo+gnPlKSzYAOE9dY3qG
znSxGIm6a7HXFV7ADwCkhESs2nx6gOnybTpMZc0CziGzWczJMvhf1H+uDjOT3Z+G
MujBXc98DXKj4Wj5+2SEkd0nNflW6rYkfHvJdvtyKaSOmixtXrNflOYuFX38/iNf
j+QPrGM79Ue0+CvegauaHAOoNh+R0QJpLKSldwWswcnHF4UT0ipIhmORSd69euvE
IwLn+BF35jQQZwMwl5DVIPpCifRzS/FE0qm5TzcWyglZ2/ViOI6bVdCHiiY+Q1bz
zP/z6UZgQky+Yj8X97HagcsMyJWgYIJAVsuPQWf/y5mx00MUwjdBMxhIqEjH3het
SHgukIE8LQTtuTWzZoT5M0t4/6CAtLJ10PPOWjX50Qq0rWS+qCLSKuChWhZt2gEe
IWJOzPmje+dpivicKeC1jgkh4F61WYYDnFn9rfM7N2Emmdok4Wc=
=cueR
-----END PGP SIGNATURE-----

--enhac5oladjw6qms--