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

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

Hi Joseph,

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 attempt=
=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 overall=
=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 thes=
e=20
> ones without corresponding wcsto* functions into a logically coherent=20
> design.

Okay, let's try with some more rationale:

NetBSD has strtoi/u(3), but not wcstoi/u(3), AFAICS.  This is prior art.

I don't feel qualified to propose a function for a family (wchar.h)
which I have never used myself, nor implemented.

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.

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.

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.

> (I don't care about Annex K myself - but I still made sure that my recent=
=20
> report of issue 1012 included the relevant Annex K edits.)
>=20
> > > I'm also concerned that the names sound like int / unsigned int analo=
gues=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 existing=
=20
> name is defective through suggesting an incorrect analogy, that would be =
a=20
> reasonable basis to choose a new one.

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


Have a lovely night!
Alex

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

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

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

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmfZ5y0ACgkQ64mZXMKQ
wqm80w/9GQABzeKXvU2/jbKia8mkKlg35l+2Z2jxs3epQr1K9hbISIt11r0kApVR
NfLTDqt+SwH2E4WQuBd7XSdaBm7kBPwvRVteAIjPyIJwpwsQc1ihj6FHqZWnjm0D
/dOe20eBIZwzYFmbWb8Pw+OkTarGIP/ILgPzwtkU42QDTgrTnMh1hth8X6l0Ffeb
SbTeuAO9k2IWedzlK5IRCjfYxB51KEDpIhZ+kBbZqFJGFn0wcCIJvaATNbNa4tY/
JrXDv1WCcE0Uk38nJKOxjmE4OJGR6pmdmcGEvDLnn6t/pDG/MYzrwW3ONkrYgrRD
am9QY6XEII++jmFVwEpsFepCpUyABUkoiHcFEfyss/ufBm0CfC94MWaMw06297BQ
/TKDhfkhWGyi6EjWUCJP4EkEsRoXdvDS128Qlh8gEo8HEoRxYOtH2seweTKF4apt
6uzJ0LUS/Qf1NFr9WwJZ6BTWwRb+JUGSZD+eC2BeBGT+NJhiylGThYcwiK0PAnUv
NBCPoGJwXhg6idub/jXDrS1TWb2l1oh4u1SVWN8WGHT5j2C5fSSNSxwXMgnATNUu
a7tvEUcmGxKZ+87u6sKW7V8MIhpuuOI0yDMj6/Esu2+RKsN307CPNCSzyGMYil7f
AK0a/eWOGPlFVPhQNNWqwNokHSy1SDik7kh2K3SfX7r5qP4dRC0=
=m5z8
-----END PGP SIGNATURE-----

--33ncnshqznqgaa4g--